Do not decrement resp_count if it's already 0.
We set resp_count to 0 when the device is closed. The next open and
read will try to clear the WDM_READ flag if there was leftover data
in the read buffer. This fix is necessary to prevent resubmitting
the read URB in a tight loop because resp_count becomes negative.
The bug can easily be triggered from userspace by not reading all
data in the read buffer, and then closing and reopening the chardev.
Fixes: 8dd5cd5395 ("usb: cdc-wdm: avoid hanging on zero length reads")
Cc: <stable@vger.kernel.org> # 3.13
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>. Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 73e06865ea ("USB: cdc-wdm: support back-to-back
USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications") implemented
queued response handling. This added a new requirement: The read
urb must be resubmitted every time we clear the WDM_READ flag if
the response counter indicates that the device is waiting for a
read.
Fix by factoring out the code handling the WMD_READ clearing and
possible urb submission, calling it everywhere we clear the flag.
Without this fix, the driver ends up in a state where the read urb
is inactive, but the response counter is positive after a zero
length read. This prevents the read urb from ever being submitted
again and the driver appears to be hanging.
Fixes: 73e06865ea ("USB: cdc-wdm: support back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications")
Cc: Greg Suarez <gsuarez@smithmicro.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org> # 3.13
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
An ioctl that does depends on communication with a device should
prevent suspension of teh device.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Simple straightforward implementation. Just returning the statistics
gathered for TIOCMIWAIT
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This implements TIOCMIWAIT for TIOCM_DSR, TIOCM_RI and TIOCM_CD
Disconnect is handled as TIOCM_CD or an error.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The only notification supported by the Device Management class is
Response Available. But this driver is also used as a subdriver of
other CDC classes, allowing notifications like Speed Change and
Network Connection. This results in log messages which are only
confusing to an end user:
[66255.801874] cdc_mbim 1-3:1.5: unknown notification 42 received: index 5 len 8
These drivers use cdc-wdm as a subdriver to allow access to an
embedded management protocol, and all management is expected to
use this protocol. There is therefore no need to handle any of
these optional CDC notifications. Instead we can let the cdc-wdm
driver recognize them and log a debug level message instead of an
error.
Reported-by: Rob Gardner <robmatic@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some MBIM devices send back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications
when sending a message over multiple fragments or when there are unsolicited
messages available.
Count up the number of USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications received
and decrement the count and submit the urb for the next response each time userspace
completes a read the response.
Signed-off-by: Greg Suarez <gsuarez@smithmicro.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In auditing the usbtmc sysfs files, a bunch of them were being created
as "read only", yet they have logic to handle writing to. So fix them
up by setting the permissions properly.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix probe of Rigol devices on big-endian machines. A quirk for these
devices was introduced by commit c2e314835 ("USB: usbtmc: Set
rigol_quirk if device is listed") but was only enabled on little-endian
machines.
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is a few cases where braces are not needed. This patch removes
unnecessary '& 255' pieces as well when lvalue type is u8.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bInterval must be on the range 1 - 16, if we
want to pass the maximum allowed, we should
be passing 16
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When writing data we were:
lock
do some work
unlock
call function
lock
do some work
unlock
return
return
It turns out, that "function" was only ever called in the one place, so
instead of locking/unlocking for no good reason, just inline the
function and only grab the lock once.
This has sped up the pathological case of sending 1 byte packets to a
loop-back cdc-acm device from 49600 bytes per second to 50100 bytes a
second on my workstation. A tiny increase yes, but noticable, and now
the spinlock isn't the hottest thing on the perf graph anymore. Yes, we
are still waiting for the hardware for the most part, but getting rid of
a spinlock_irq_save() call for every packet is still a good thing.
And we end up deleting lines of code, always a win overall.
This was found by using a Teensy 3.0 device and the test program and
firmware located at:
http://www.pjrc.com/teensy/benchmark_usb_serial_receive.html
Reported-by: Paul Stoffregen <paul@pjrc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These patches implement a modification of the USBTMC
protocol to allow operation with Rigol equipment. Cosmetic change to show
that 12 is the USBTMC header size.
Signed-off-by: Alexandre Peixoto Ferreira <alexandref75@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These patches implement a modification of the USBTMC
protocol to allow operation with Rigol equipment. The usbtmc_read function is
modified so if the quirk is active, the TMC header is sent with the size of
the data as the whole size of the request. If the quirk is inactive, the TMC
request is sent once per bulk transfer and with size limited to the bulk
transfer size. In the case of the quirk, only the first response contains the
TMC header and the others are just data.
Signed-off-by: Alexandre Peixoto Ferreira <alexandref75@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These patches implement a modification of the USBTMC
protocol to allow operation with Rigol equipment. It an idVendor and
idProduct is found on the usbtmc_id_quirk array, the rigol_quirk is set for
this device.
Signed-off-by: Alexandre Peixoto Ferreira <alexandref75@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
