Keith Packard writes:
> Yup, with a few minor fixes to pass the right arguments:
Argh. Just after hitting 'send', I noticed that I'd not moved the URB
deallocation out of the way when merging the first patch in this
series. That means the driver won't build with only the first patch
applied, whi
Oliver Neukum writes:
> On Tue, 2016-02-16 at 11:09 -0800, Keith Packard wrote:
>> I could be convinced that the driver should be using a different path
>> through the USB stack that would allow a signal to wake up while
>> waiting
>> for the URB to complete, but this patch at least avoids needin
On Tue, 2016-02-16 at 11:09 -0800, Keith Packard wrote:
> I could be convinced that the driver should be using a different path
> through the USB stack that would allow a signal to wake up while
> waiting
> for the URB to complete, but this patch at least avoids needing to
> wait
> for a huge read
Oliver Neukum writes:
> why is this needed? You are doing this right after a
> mutex_lock_interruptible().
When the device isn't contended, this mutex will never block and so
mutex_lock_interruptible will never check for a signal.
I had mistakenly assumed that usb_bulk_msg would abort when a si
On Mon, 2016-02-15 at 18:49 -0800, Keith Packard wrote:
> Call signal_pending before reading a chunk of data from the device so
> that long read operations can be interrupted with a signal.
Hi,
why is this needed? You are doing this right after a
mutex_lock_interruptible().
Regards
Call signal_pending before reading a chunk of data from the device so
that long read operations can be interrupted with a signal.
Signed-off-by: Keith Packard
---
drivers/usb/misc/chaoskey.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/misc/chaoskey.c b/drivers/usb/misc
6 matches
Mail list logo
