Re: [PATCH] usb: check for signals in chaoskey read function

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

Re: [PATCH] usb: check for signals in chaoskey read function

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

Re: [PATCH] usb: check for signals in chaoskey read function

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

Re: [PATCH] usb: check for signals in chaoskey read function

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

Re: [PATCH] usb: check for signals in chaoskey read function

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

[PATCH] usb: check for signals in chaoskey read function

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