Hugo
[0] https://lore.kernel.org/patchwork/patch/1039712/
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
___
devel m
> > + list_for_each_entry(it, >futex_wait_queue_list, list) {
> > + if (wait_queue->offset == arg->offset) {
> ^^
> You meant "it->offset".
Right, this is not good. Fixed in v2.
Thanks for the feedback!
Use multiple per-offset wait queues instead of one big wait queue per
region.
Signed-off-by: Hugo Lefeuvre
---
Changes in v2:
- dereference the it pointer instead of wait_queue (which is not set
yet) in handle_vsoc_cond_wait()
---
drivers/staging/android/TODO | 4 ---
drivers/staging
> > Use multiple per-offset wait queues instead of one big wait queue per
> > region.
> >
> > Signed-off-by: Hugo Lefeuvre
>
> Have you tested this?
>
> Noticed any performance speedups or slow downs?
Not yet. I have started to set up a cuttlefish test env
Use multiple per-offset wait queues instead of one big wait queue per
region.
Signed-off-by: Hugo Lefeuvre
---
This patch is based on the simplify handle_vsoc_cond_wait patchset,
currently under review: https://lkml.org/lkml/2019/2/7/870
---
drivers/staging/android/TODO | 4 ---
drivers
ael (power maintainer) on it.
Thanks, I have splitted the patch set[0][1] and submitted the
freezable_schedule patch separately (only cc-ing people responsible
for the wait api + Rafael).
regards,
Hugo
[0] https://lkml.org/lkml/2019/2/7/802
[1] https://lkml.org/lkml/2019/2/7/870
--
simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using newly
added wait_event_freezable_hrtimeout helper and remove duplicate include.
Signed-off-by: Hugo Lefeuvre
---
Changes in v2:
- Fix removal of necessary linux/freezer.h include.
- Make commit message more precise about
introduce wait_event_freezable_hrtimeout, an interruptible and freezable
version of wait_event_hrtimeout.
This helper will allow for simplifications in staging/android/vsoc.c, among
others.
Signed-off-by: Hugo Lefeuvre
---
Changes in v2:
- No change.
include/linux/wait.h | 25
: use freezable_schedule when possible",
it was submitted separately.
- Patch 3/3 (now 2/2): Fix removal of a necessary linux/freezer.h
include and improve commit message.
[1] v1: https://lkml.org/lkml/2019/2/1/19
Hugo Lefeuvre (2):
sched/wait: introduce wait_event_freezable_hrtimeout
lines in kern.log.
Results:
Without my patch: 448 calls freeze_task, 12 skipped.
With my patch: 448 calls, 32 skipped.
2.6x more tasks skipped.
Not sure this is the best way to test this patch, though. Any advice?
regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.c
emoves a necessary #include
. I will submit an updated version tomorrow.
Thanks for the review!
regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2
egards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
___
devel mailing l
simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using newly
added wait_event_freezable_hrtimeout helper and remove useless includes.
Signed-off-by: Hugo Lefeuvre
---
drivers/staging/android/vsoc.c | 69 +-
1 file changed, 10 insertions(+), 59
try_to_freeze() when they
wake up if the freeze is still underway.
It is not a problem since sleeping tasks can't do anything which isn't
allowed for a frozen task while sleeping.
The result is a potential performance gain during freeze, since less
tasks have to be awaken.
Signed-off-by: Hugo
introduce wait_event_freezable_hrtimeout, an interruptible and freezable
version of wait_event_hrtimeout.
Among others this helper will allow for simplifications in
staging/android/vsoc.c.
Signed-off-by: Hugo Lefeuvre
---
include/linux/wait.h | 25 +
1 file changed, 21
[0] https://lkml.org/lkml/2019/1/17/877
[1] https://lkml.org/lkml/2019/1/19/58
Hugo Lefeuvre (3):
sched/wait: use freezable_schedule when possible
sched/wait: introduce wait_event_freezable_hrtimeout
staging/android: simplify handle_vsoc_cond_wait
drivers/staging/android/v
regards,
Hugo
[0] https://elixir.bootlin.com/linux/latest/source/include/linux/freezer.h#L103
[1]
https://elixir.bootlin.com/linux/latest/source/Documentation/power/freezing-of-tasks.txt#L90
[2] https://elixir.bootlin.com/linux/latest/source/kernel/kthread.c#L569
--
Hugo Lefeuvr
during the schedule() call, but in the end try_to_freeze() is still
called so the result is the same, right?
I wonder why wait_event_freezable is not calling freezable_schedule().
That being said, I am not sure that the try_to_freeze() call does anything
in the vsoc case because there is no
Hi Greg,
> > introduce wait_event_freezable_hrtimeout, an interruptible and freezable
> > version of wait_event_hrtimeout.
> >
> > simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using this
> > newly added helper and remove useless includes.
> &g
introduce wait_event_freezable_hrtimeout, an interruptible and freezable
version of wait_event_hrtimeout.
simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using this
newly added helper and remove useless includes.
Signed-off-by: Hugo Lefeuvre
---
drivers/staging/android/vsoc.c
> It should probably say "address."
Thanks. I'm working on a few patches for staging/android, this issue will
be addressed as well.
regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 3
. So,
once VSOC_SELF_INTERRUPT has been executed once,
VSOC_WAIT_FOR_INCOMING_INTERRUPT doesn't work anymore ?
Thanks for your work !
cheers,
Hugo
PS: cc-ing the result of get_maintainer.pl + contacts from todo. Please
tell me if this is not the right way to go.
--
Hugo Lef
fault
values of the rf69 datasheet[0] ?
Also, is there a specific reason why you chose 4711 as a default value
for the bit rate ? I couldn't find it anywhere in the datasheet nor on
the internet.
Thanks !
Regards,
Hugo
[0] http://www.hoperf.com/upload/rf/RFM69CW-V1.1.pdf
--
Hugo L
nted to have your opinion
> > on this.
>
> Agree.
I'll prepare a patch addressing both issues. However I don't own test devices
so it would be really great if you could test it !
I'm currently thinking of adapting this driver for other HopeRf modules like
RFM69HCW or RFM12 so I will pro
On Wed, Jun 20, 2018 at 11:34:39AM +0300, Dan Carpenter wrote:
> On Tue, Jun 19, 2018 at 10:33:26PM -0400, Hugo Lefeuvre wrote:
> > @@ -1178,6 +1152,11 @@ static int pi433_probe(struct spi_device *spi)
> > device->tx_active = false;
> > device->i
counter and move rx buffer {de,}allocation to probe()
and remove(). Remove associated dead code from open() and release().
Remove related TODO entry from ioctl().
Signed-off-by: Hugo Lefeuvre
---
Changes in v3:
- add missing free call in probe() (in case of failure during
memory allocation
counter and move rx buffer {de,}allocation to probe()
and remove(). Remove associated dead code from open() and release().
Remove related TODO entry from ioctl().
Signed-off-by: Hugo Lefeuvre
---
Changes in v2:
- Remove useless users counter.
- Remove unneeded TODO entry in ioctl
/* make sure ops on existing fds can abort cleanly */
> > 1297 device->spi = NULL;
>
> That's when we're unloading the module so there aren't any users left.
I'll submit an updated version of my patch getting rid of the counter
and addressing the remaining race conditions.
Thanks
ces:
1296 /* make sure ops on existing fds can abort cleanly */
1297 device->spi = NULL;
Thanks for your time !
Regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
___
f minor_lock in pi433_open().
Signed-off-by: Hugo Lefeuvre
---
drivers/staging/pi433/pi433_if.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 94e0bfcec991..73c511249f7f 100644
--- a/drivers/staging/pi43
fixed in v4. Sorry for the noise.
--
Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriv
if (copy_from_user(_cfg_buffer, argp,
> > + sizeof(struct pi433_tx_cfg))) {
>
> Sorry for the duplicate review, but it got sent to both my inboxes... :P
Thanks for your review ! Patch updated.
Please tell me if you don't to be CC-ed anymore. :)
regard
_CFG case in pi433_ioctl.
Also, do not copy data directly from user space to instance->tx_cfg.
Instead use a temporary buffer allowing future checks for correctness
of copied data and simpler code.
Signed-off-by: Hugo Lefeuvre
---
Changes in v4:
- Fix incorrect buffer name in memcpy.
---
drivers/s
_CFG case in pi433_ioctl.
Also, do not copy data directly from user space to instance->tx_cfg.
Instead use a temporary buffer allowing future checks for correctness
of copied data and simpler code.
Signed-off-by: Hugo Lefeuvre
---
Changes in v3:
- Use tx_cfg for the name of temporary buffer (sho
_CFG case in pi433_ioctl.
Also, do not copy data directly from user space to instance->tx_cfg.
Instead use a temporary buffer allowing future checks for correctness
of copied data.
Signed-off-by: Hugo Lefeuvre
---
Changes in v2:
- Use device->tx_fifo_lock instead of introducing a new lock in
en to the fifo by
pi433_write.
What kind of checks do you want to perform exactly ?
But, right, I prefer the idea of the temporary buffer too, and seeing the
rest of kernel code it seems to be the usual way to go.
Regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
4096
don't even need to introduce a new lock, using
device->tx_fifo_lock should be fine. I'll update the patch.
--
Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
signature.asc
Descript
enter in an inconsistent state.
Add a mutex making sure that the PI433_IOC_WR_TX_CFG case will never
be run by several threads concurrently.
Signed-off-by: Hugo Lefeuvre
---
drivers/staging/pi433/pi433_if.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging
test it because I don't have test
devices.
--
Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
_data, which
> wraps struct pi433_instance and its mutex.
>
> Make filp->private_data point to a struct pi433_data, allowing to
> acquire the lock before accessing the struct pi433_instance.
>
> Signed-off-by: Hugo Lefeuvre
> ---
> Changes in v2:
> - Use mutex
nything, simply expose API)
I'd really prefer going for the first one, but I wanted to have your opinion
on this.
Thanks for your work !
Best regards,
Hugo
[0] http://www.hoperf.com/upload/rf/RFM69CW-V1.1.pdf
[CC-ing Valentin Vidic, he was quite active on the pi433 driver these
last months]
wrapper struct pi433_data which would contain
pointers to the pi433_instance and its mutex. I couldn't find any
similar situation in the kernel, so I'm not sure it's the right way to
go though.
Thanks !
Regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0
ilp->private_data point to a struct pi433_data, allowing to
acquire the lock before accessing the struct pi433_instance.
Signed-off-by: Hugo Lefeuvre
---
Changes in v2:
- Use mutex instead of rw semaphore.
- Introduce struct pi433_data in order to allow functions t
dn't notice it. Thanks !
Otherwise, do you think the usage of rw semaphore is appropriate in this
case ?
Regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
___
devel mailing
lso affect pi433_write and pi433_read.
The newly introduced semaphore makes sure that filp->private_data
will not be freed by pi433_release (writer) as long as pi433_write,
pi433_read or pi433_ioctl (readers) are still executing.
Signed-off-by: Hugo Lefeuvre
---
drivers/staging/pi433/pi433_if.
45 matches
Mail list logo