rndis/cdc_ether usb device causing Oops in 4.4rc1+ with NULL dereference

[Vasily Galkin]

rm *rc1*dmesgAfter switching from 4.3 to 4.4rc-s plugging device ID 1076:8002 
GCT Semiconductor, Inc. LU150 LTE Modem [Yota LU150] causes kernel Oops.

The Oops is always reproducible when this device is plugged or system is booted 
with it.
Oops reproduced with debian's 4.4.rc6 and vanilla 4.4rcs 
(http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc1+cod1-wily/, tryied 
without nvidia blob)
After the oops system is semioperable - for example lsusb and rebooting hangs.

With debian's 4.3.0 and vanilla 4.3.3 
(http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.3.3-wily/) all works neraly 
fine - device never causes Oops but rarely silently doesn't work showing that 
cdc_ether driver is in use instead of typical rndis_host.

Here is the most interesting parts of Oops, full in attahced dmesg

[ 7.321232] BUG: unable to handle kernel NULL pointer dereference at 
0003
[ 7.321340] IP: [] usbnet_generic_cdc_bind+0x156/0x6e0 
[cdc_ether]
[ 7.323831] CPU: 2 PID: 374 Comm: systemd-udevd Tainted: P O 4.4.0-rc6-amd64 #1 
Debian 4.4~rc6-1~exp1
[ 7.324050] RIP: 0010:[] [] 
usbnet_generic_cdc_bind+0x156/0x6e0 [cdc_ether]
[ 7.324157] RSP: 0018:8802362939f8 EFLAGS: 00010286
[ 7.324210] RAX:  RBX: 880232cf5840 RCX: 0003
[ 7.325282] Call Trace:
[ 7.325336] [] ? pcpu_alloc_area+0x220/0x3e0
[ 7.325395] [] ? generic_rndis_bind+0x60/0x510 [rndis_host]
[ 7.325469] [] ? usbnet_probe+0x31c/0x8d0 [usbnet]
[ 7.325527] [] ? __pm_runtime_set_status+0x185/0x230
[ 7.325597] [] ? usb_probe_interface+0x1b3/0x300 [usbcore]
[ 7.325655] [] ? driver_probe_device+0x212/0x480
[ 7.325711] [] ? __driver_attach+0x7b/0x80
[ 7.325766] [] ? driver_probe_device+0x480/0x480
[ 7.325822] [] ? bus_for_each_dev+0x67/0xb0
[ 7.325877] [] ? bus_add_driver+0x1df/0x270
[ 7.325932] [] ? driver_register+0x57/0xc0
[ 7.325997] [] ? usb_register_driver+0x7d/0x130 [usbcore]
[ 7.326053] [] ? 0xa0dd7000
[ 7.326108] [] ? do_one_initcall+0xb2/0x200
[ 7.326164] [] ? do_init_module+0x5b/0x1dc
[ 7.326220] [] ? load_module+0x2173/0x2780
[ 7.326275] [] ? __symbol_put+0x60/0x60
[ 7.326330] [] ? kernel_read+0x4b/0x70
[ 7.326386] [] ? SyS_finit_module+0xae/0xe0
[ 7.326442] [] ? system_call_fast_compare_end+0xc/0x67

Since lsusb is not working on problemtic kernels with plugged device attaching 
lsusb -v output from 4.3 kernel and lsusb -v output from 4.4 kernel with 
unplugged device.

Also attaching dmesg of good boot with 4.3 and disassembly with debug symbols 
of cdc_ether module corresponding to Oops trace.

According to disassembly symbols kernel oopses while trying to read adress 0x3 
while executing drivers/net/usb/cdc_ether.c line 167-168:
info->control = usb_ifnum_to_if(dev->udev,
info->u->bMasterInterface0);
with info->u=%rax somehow appears to be NULL (and bMasterInterface0 is offset 
3).

This code was changed last time in b0f85fa11aefc4f3e03306b4cd47f113bd57dcba and 
merged into mainline with b0f85fa11aefc4f3e03306b4cd47f113bd57dcba at 2015-11-04
Attachments in archive:
44rndis_oops/4.3.0-debian.dmesg
44rndis_oops/4.3.0-debian.lsusb-v
44rndis_oops/4.4rc1-vanilla-without-device.lsusb-t
44rndis_oops/4.3.0-debian.lsusb-t
44rndis_oops/4.4rc6-debian.dmesg
44rndis_oops/4.4rc6-debian.cdc_ether.objdump
44rndis_oops/4.4rc1-vanilla-without-device.lsusb-v


44rndis_oops.tar.gz
Description: GNU Zip compressed data

RE: [PATCH] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

[Peter Chen]

 
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Wednesday, December 30, 2015 7:34 PM
> To: ba...@ti.com
> Cc: Peter Chen ; stefan.wah...@i2se.com; linux-
> u...@vger.kernel.org; Fabio Estevam 
> Subject: [PATCH] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for
> mx23/mx28
> 
> From: Fabio Estevam 
> 
> On a mx28 board with a USB hub the following error is observed:
> 
> hub 1-1:1.0: USB hub found
> hub 1-1:1.0: 2 ports detected
> usb 1-1: USB disconnect, device number 2 usb usb1-port1: cannot reset (err = -
> 32) usb usb1-port1: cannot reset (err = -32) usb usb1-port1: cannot reset 
> (err =
> -32) usb usb1-port1: cannot reset (err = -32) usb usb1-port1: cannot reset 
> (err =
> -32) usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
> 
> ,which is caused by a problem described by the
> MXS_PHY_ABNORMAL_IN_SUSPEND flag.
> 
> As we currently do not have a proper implementation for this issue, one
> possible workaround is to pass "usbcore.autosuspend=-1" in the kernel
> command line, so add this suggestion into the
> MXS_PHY_ABNORMAL_IN_SUSPEND flag description.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  drivers/usb/phy/phy-mxs-usb.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index c2936dc..453a5ab 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -98,6 +98,10 @@
>   * The PHY will be in messy if there is a wakeup after putting
>   * bus to suspend (set portsc.suspendM) but before setting PHY to low
>   * power mode (set portsc.phcd).
> + *
> + * To work around this problem on mx23/mx28 user should pass
> + * "usbcore.autosuspend=-1" in the kernel command line for now, as
> + * we do not have a proper fix for this flag in the kernel yet.
>   */
>  #define MXS_PHY_ABNORMAL_IN_SUSPEND  BIT(1)
> 
> --
> 1.9.1

Acked-by: Peter Chen 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

xHCI driver issue (ASMedia Controller using xhci_hcd)

[Johannes Bauer]

Hi list,

I originally posted this on libusb-devel [1], but got a friendly
redirect here by Alan Stern, hope this is the right place!

Let me describe my problem from a "user" standpoint before diving into
the technical details: USB 3.0 does not work on my PC flat out.
Sometimes USB 3.0 ports work for /some/ USB 2.0 devices, but most of the
time they don't at all (e.g. RS232 converters will show up at first but
have transmission errors once I open the tty device, etc.). If they do
work, they're flaky as hell. All USB 3.0 ports are, for all practical
purposes, unusable on my system (even with USB 2 devices attached).

Here's an example of a USB 3.0 device (ix500 scanner) and what happens
when I plug it in:

$ dmesg
[  167.736631] usb 8-1: new SuperSpeed USB device number 2 using xhci_hcd
[  167.756492] usb 8-1: New USB device found, idVendor=04c5, idProduct=132b
[  167.756497] usb 8-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[  167.756500] usb 8-1: Product: ScanSnap iX500
[  167.756503] usb 8-1: Manufacturer: Fujitsu

(note this is a freshly booted system, no previous suspend/hiberate
going on).

Then I try to scan with it:

$ scanimage
scanimage: open of device fujitsu:ScanSnap iX500:9768 failed: Error
during device I/O

No log output is shown in dmesg. Subsequent attempts to scan with the
device yield:

$ scanimage
scanimage: no SANE devices found

Note that the scanner works perfectly on my USB 2.0 ports of the system
and it works perfectly on the exact same USB 3.0 ports under Windows (I
bit the bullet, installed Windows 7, and tried that out just today).

Some details about my system: I'm using an MSI X99S-SLI PLUS (BIOS v1.9,
latest one) motherboard. The xhci controller is a ASMedia brand:

$ lspci -nn | grep -i asme
06:00.0 USB controller [0c03]: ASMedia Technology Inc. Device [1b21:1142]

I'm running Linux Mint x86_64. The problem occured with the stock
3.16.0-38-generic #52~14.04.1-Ubuntu SMP kernel, but I've also just now
compiled the latest stable 4.3.3 and can reproduce the exact same
problem with it.

Let's look at a strace of the first scanimage call:

$ strace -ff scanimage
[...]
open("/dev/bus/usb/008/005", O_RDWR)= 3
ioctl(3, USBDEVFS_CLAIMINTERFACE, 0x7ffe9ccfa08c) = 0
ioctl(3, USBDEVFS_SUBMITURB, 0x7ffe9ccf9ec0) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0x7ffe9ccf9e88) = 0
ioctl(3, USBDEVFS_SUBMITURB, 0x7ffe9ccf9ec0) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0x7ffe9ccf9e88) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, NULL, [3], NULL, {0, 1000})   = 0 (Timeout)
ioctl(3, USBDEVFS_REAPURBNDELAY, 0x7ffe9ccf9e88) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, NULL, [3], NULL, {0, 1000})   = 0 (Timeout)
ioctl(3, USBDEVFS_REAPURBNDELAY, 0x7ffe9ccf9e88) = -1 EAGAIN (Resource
temporarily unavailable)

[this repeats about 1300 times, interrupted two times by:]

ioctl(3, USBDEVFS_DISCARDURB, 0x7ffe9ccf9ec0) = 0
ioctl(3, USBDEVFS_REAPURB, 0x7ffe9ccf9e88) = 0
ioctl(3, SNDRV_CTL_IOCTL_ELEM_UNLOCK or USBDEVFS_CLEAR_HALT,
0x7ffe9ccf9f9c) = 0
ioctl(3, USBDEVFS_SUBMITURB, 0x7ffe9ccf9ec0) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0x7ffe9ccf9e88) = 0
ioctl(3, USBDEVFS_SUBMITURB, 0x7ffe9ccf9ec0) = 0

[and finally]

ioctl(3, USBDEVFS_REAPURBNDELAY, 0x7ffe9ccf9e88) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, NULL, [3], NULL, {0, 1000})   = 0 (Timeout)
ioctl(3, USBDEVFS_REAPURBNDELAY, 0x7ffe9ccf9e88) = -1 EAGAIN (Resource
temporarily unavailable)
ioctl(3, USBDEVFS_DISCARDURB, 0x7ffe9ccf9ec0) = 0
ioctl(3, USBDEVFS_REAPURB, 0x7ffe9ccf9e88) = 0
ioctl(3, SNDRV_CTL_IOCTL_ELEM_UNLOCK or USBDEVFS_CLEAR_HALT,
0x7ffe9ccf9f9c) = 0
ioctl(3, USBDEVFS_SETINTERFACE, 0x7ffe9ccfa0b0) = 0
ioctl(3, SNDRV_CTL_IOCTL_ELEM_LIST or USBDEVFS_RELEASEINTERFACE,
0x7ffe9ccfa0dc) = 0
close(3)= 0
write(2, "scanimage: open of device fujits"..., 86scanimage: open of
device fujitsu:ScanSnap iX500:9768 failed: Error during device I/O
) = 86

Then, on the second call, during device discovery, something similar:

$ strace -ff scanimage
[...]
open("/dev/bus/usb/008/004", O_RDWR)= 4
ioctl(4, USBDEVFS_CLAIMINTERFACE, 0x7ffdcbcacfbc) = 0
ioctl(4, USBDEVFS_SUBMITURB, 0x7ffdcbcacdf0) = 0
ioctl(4, USBDEVFS_REAPURBNDELAY, 0x7ffdcbcacdb8) = 0
ioctl(4, USBDEVFS_SUBMITURB, 0x7ffdcbcacdf0) = 0
ioctl(4, USBDEVFS_REAPURBNDELAY, 0x7ffdcbcacdb8) = -1 EAGAIN (Resource
temporarily unavailable)
select(5, NULL, [4], NULL, {0, 1000})   = 0 (Timeout)
ioctl(4, USBDEVFS_REAPURBNDELAY, 0x7ffdcbcacdb8) = -1 EAGAIN (Resource
temporarily unavailable)
select(5, NULL, [4], NULL, {0, 1000})   = 0 (Timeout)
[... tons of repeats ...]
ioctl(4, USBDEVFS_REAPURBNDELAY, 0x7ffdcbcacdb8) = -1 EAGAIN (Resource
temporarily unavailable)
select(5, NULL, [4], NULL, {0, 1000})   = 0 (Timeout)
ioctl(4, USBDEVFS_REAPURBNDELAY, 0x7ffdcbcacdb8) = -1 EAGAIN (Resource
temporarily unavailable)
ioctl(4, USBDEVFS_DISCARDURB, 0x7ffdcbcacdf0) = 0
ioctl(4, USBDEVFS_REAPURB, 0x7ffdcbcacdb8) = 0
ioctl(4, 

ERROR Transfer event for disabled endpoint or incorrect stream ring

[U.Mutlu]

While copying a disk with the dd command from inside a live-CD-boot-system
the following single error has been printed:

xhci_hcd ERROR Transfer event for disabled endpoint or incorrect stream ring
@000212409100   0a00 02088001

Does anybody know what these numbers mean?

But other than that, everything seems ok.
This was a backup of the whole disk.
fsck on both disks does not report any errors.

I wonder if it would be possible with the numbers to locate the affected file?


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] usb: gadget: f_midi: refactor state machine

[Felipe F. Tonello]

This refactor results in a cleaner state machine code and as a result fixed a
bug when packaging a MIDI-USB packet right after a non-conformant MIDI byte 
stream.

Signed-off-by: Felipe F. Tonello 
---
 drivers/usb/gadget/function/f_midi.c | 204 ++-
 1 file changed, 129 insertions(+), 75 deletions(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index fb1fe96d3215..c4b47f68e553 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -50,6 +50,19 @@ static const char f_midi_longname[] = "MIDI Gadget";
  */
 #define MAX_PORTS 16
 
+/* MIDI message states */
+enum {
+   STATE_INITIAL = 0,  /* pseudo state */
+   STATE_1PARAM,
+   STATE_2PARAM_1,
+   STATE_2PARAM_2,
+   STATE_SYSEX_0,
+   STATE_SYSEX_1,
+   STATE_SYSEX_2,
+   STATE_REAL_TIME,
+   STATE_FINISHED, /* pseudo state */
+};
+
 /*
  * This is a gadget, and the IN/OUT naming is from the host's perspective.
  * USB -> OUT endpoint -> rawmidi
@@ -60,13 +73,6 @@ struct gmidi_in_port {
int active;
uint8_t cable;
uint8_t state;
-#define STATE_UNKNOWN  0
-#define STATE_1PARAM   1
-#define STATE_2PARAM_1 2
-#define STATE_2PARAM_2 3
-#define STATE_SYSEX_0  4
-#define STATE_SYSEX_1  5
-#define STATE_SYSEX_2  6
uint8_t data[2];
 };
 
@@ -400,118 +406,166 @@ static int f_midi_snd_free(struct snd_device *device)
return 0;
 }
 
-static void f_midi_transmit_packet(struct usb_request *req, uint8_t p0,
-   uint8_t p1, uint8_t p2, uint8_t p3)
-{
-   unsigned length = req->length;
-   u8 *buf = (u8 *)req->buf + length;
-
-   buf[0] = p0;
-   buf[1] = p1;
-   buf[2] = p2;
-   buf[3] = p3;
-   req->length = length + 4;
-}
-
 /*
  * Converts MIDI commands to USB MIDI packets.
  */
 static void f_midi_transmit_byte(struct usb_request *req,
 struct gmidi_in_port *port, uint8_t b)
 {
-   uint8_t p0 = port->cable << 4;
+   uint8_t p[4] = { port->cable << 4, 0, 0, 0 };
+   uint8_t next_state = STATE_INITIAL;
+
+   switch (b) {
+   case 0xf8 ... 0xff:
+   /* System Real-Time Messages */
+   p[0] |= 0x0f;
+   p[1] = b;
+   next_state = port->state;
+   port->state = STATE_REAL_TIME;
+   break;
 
-   if (b >= 0xf8) {
-   f_midi_transmit_packet(req, p0 | 0x0f, b, 0, 0);
-   } else if (b >= 0xf0) {
+   case 0xf7:
+   /* End of SysEx */
+   switch (port->state) {
+   case STATE_SYSEX_0:
+   p[0] |= 0x05;
+   p[1] = 0xf7;
+   next_state = STATE_FINISHED;
+   break;
+   case STATE_SYSEX_1:
+   p[0] |= 0x06;
+   p[1] = port->data[0];
+   p[2] = 0xf7;
+   next_state = STATE_FINISHED;
+   break;
+   case STATE_SYSEX_2:
+   p[0] |= 0x07;
+   p[1] = port->data[0];
+   p[2] = port->data[1];
+   p[3] = 0xf7;
+   next_state = STATE_FINISHED;
+   break;
+   default:
+   /* Ignore byte */
+   next_state = port->state;
+   port->state = STATE_INITIAL;
+   }
+   break;
+
+   case 0xf0 ... 0xf6:
+   /* System Common Messages */
+   port->data[0] = port->data[1] = 0;
+   port->state = STATE_INITIAL;
switch (b) {
case 0xf0:
port->data[0] = b;
-   port->state = STATE_SYSEX_1;
+   port->data[1] = 0;
+   next_state = STATE_SYSEX_1;
break;
case 0xf1:
case 0xf3:
port->data[0] = b;
-   port->state = STATE_1PARAM;
+   next_state = STATE_1PARAM;
break;
case 0xf2:
port->data[0] = b;
-   port->state = STATE_2PARAM_1;
+   next_state = STATE_2PARAM_1;
break;
case 0xf4:
case 0xf5:
-   port->state = STATE_UNKNOWN;
+   next_state = STATE_INITIAL;
break;
case 0xf6:
-   f_midi_transmit_packet(req, p0 | 0x05, 0xf6, 0, 0);
-   port->state = STATE_UNKNOWN;
-   break;
-   case 0xf7:
-   switch (port->state) {
-   case 

[PATCH 2/4] usb: gadget: f_midi: added spinlock on transmit function

[Felipe F. Tonello]

Since f_midi_transmit is called by both ALSA and USB frameworks, it can
potentially cause a race condition between both calls. This is bad because the
way f_midi_transmit is implemented can't handle concurrent calls. This is due
to the fact that the usb request fifo looks for the next element and only if
it has data to process it enqueues the request, otherwise re-uses it. If both
(ALSA and USB) frameworks calls this function at the same time, the
kfifo_seek() will return the same usb_request, which will cause a race
condition.

To solve this problem a syncronization mechanism is necessary. In this case it
is used a spinlock since f_midi_transmit is also called by usb_request->complete
callback in interrupt context.

On benchmarks realized by me, spinlocks were more efficient then scheduling
the f_midi_transmit tasklet in process context and using a mutex to
synchronize. Also it performs better then previous implementation that
allocated a usb_request for every new transmit made.

Signed-off-by: Felipe F. Tonello 
---
 drivers/usb/gadget/function/f_midi.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index c4b47f68e553..bbff20697f76 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -98,6 +99,7 @@ struct f_midi {
/* This fifo is used as a buffer ring for pre-allocated IN usb_requests 
*/
DECLARE_KFIFO_PTR(in_req_fifo, struct usb_request *);
unsigned int in_last_port;
+   spinlock_t transmit_lock;
 };
 
 static inline struct f_midi *func_to_midi(struct usb_function *f)
@@ -589,12 +591,15 @@ static void f_midi_drop_out_substreams(struct f_midi 
*midi)
 static void f_midi_transmit(struct f_midi *midi)
 {
struct usb_ep *ep = midi->in_ep;
+   unsigned long flags;
bool active;
 
/* We only care about USB requests if IN endpoint is enabled */
if (!ep || !ep->enabled)
goto drop_out;
 
+   spin_lock_irqsave(>transmit_lock, flags);
+
do {
struct usb_request *req = NULL;
unsigned int len, i;
@@ -606,14 +611,17 @@ static void f_midi_transmit(struct f_midi *midi)
len = kfifo_peek(>in_req_fifo, );
if (len != 1) {
ERROR(midi, "%s: Couldn't get usb request\n", __func__);
+   spin_unlock_irqrestore(>transmit_lock, flags);
goto drop_out;
}
 
/* If buffer overrun, then we ignore this transmission.
 * IMPORTANT: This will cause the user-space rawmidi device to 
block until a) usb
 * requests have been completed or b) snd_rawmidi_write() times 
out. */
-   if (req->length > 0)
+   if (req->length > 0) {
+   spin_unlock_irqrestore(>transmit_lock, flags);
return;
+   }
 
for (i = midi->in_last_port; i < MAX_PORTS; i++) {
struct gmidi_in_port *port = midi->in_port[i];
@@ -665,6 +673,8 @@ static void f_midi_transmit(struct f_midi *midi)
}
} while (active);
 
+   spin_unlock_irqrestore(>transmit_lock, flags);
+
return;
 
 drop_out:
@@ -1270,6 +1280,8 @@ static struct usb_function *f_midi_alloc(struct 
usb_function_instance *fi)
if (status)
goto setup_fail;
 
+   spin_lock_init(>transmit_lock);
+
++opts->refcnt;
mutex_unlock(>lock);
 
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] More improvements on MIDI gadget function

[Felipe F. Tonello]

Patch 1:
  The main improvement is the refactor of the state machine MIDI parser.
  It is better to read and handles states properly, even weird ones.

Patch 3:
  Fix a race condition.

Patches 3-4:
  Miscelaneous fixes.

Felipe F. Tonello (4):
  usb: gadget: f_midi: refactor state machine
  usb: gadget: f_midi: added spinlock on transmit function
  usb: gadget: f_midi: remove useless midi reference from port struct
  usb: gadget: f_midi: add mutex_unlock under setup_fail label

 drivers/usb/gadget/function/f_midi.c | 223 ++-
 1 file changed, 143 insertions(+), 80 deletions(-)

-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] usb: gadget: f_midi: remove useless midi reference from port struct

[Felipe F. Tonello]

Signed-off-by: Felipe F. Tonello 
---
 drivers/usb/gadget/function/f_midi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index bbff20697f76..b7d3f5a10bf0 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -70,7 +70,6 @@ enum {
  * USB <- IN endpoint  <- rawmidi
  */
 struct gmidi_in_port {
-   struct f_midi *midi;
int active;
uint8_t cable;
uint8_t state;
@@ -1256,7 +1255,6 @@ static struct usb_function *f_midi_alloc(struct 
usb_function_instance *fi)
goto setup_fail;
}
 
-   port->midi = midi;
port->active = 0;
port->cable = i;
midi->in_port[i] = port;
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] usb: gadget: f_midi: add mutex_unlock under setup_fail label

[Felipe F. Tonello]

This ensures that at any point on the function if a goto to setup_fail is
made, it will unlock the mutex.

Signed-off-by: Felipe F. Tonello 
---
 drivers/usb/gadget/function/f_midi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index b7d3f5a10bf0..1255f8a898d0 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -1251,7 +1251,6 @@ static struct usb_function *f_midi_alloc(struct 
usb_function_instance *fi)
 
if (!port) {
status = -ENOMEM;
-   mutex_unlock(>lock);
goto setup_fail;
}
 
@@ -1264,7 +1263,6 @@ static struct usb_function *f_midi_alloc(struct 
usb_function_instance *fi)
midi->id = kstrdup(opts->id, GFP_KERNEL);
if (opts->id && !midi->id) {
status = -ENOMEM;
-   mutex_unlock(>lock);
goto setup_fail;
}
midi->in_ports = opts->in_ports;
@@ -1293,6 +1291,7 @@ static struct usb_function *f_midi_alloc(struct 
usb_function_instance *fi)
return >func;
 
 setup_fail:
+   mutex_unlock(>lock);
for (--i; i >= 0; i--)
kfree(midi->in_port[i]);
kfree(midi);
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 04/11] usbip: kernel module for userspace URBs transmission

[kbuild test robot]

Hi Nobuo,

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.4-rc7 next-20151223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Nobuo-Iwata/usbip-features-to-USB-over-WebSocket/20151230-150013
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> drivers/usb/usbip/usbip_ux.c:163:14: sparse: incompatible types in 
>> comparison expression (different address spaces)
   drivers/usb/usbip/usbip_ux.c:281:14: sparse: incompatible types in 
comparison expression (different address spaces)
   drivers/usb/usbip/usbip_ux.c:400:14: sparse: incompatible types in 
comparison expression (different address spaces)

vim +163 drivers/usb/usbip/usbip_ux.c

   147  if (ret) {
   148  return ret;
   149  } else if (USBIP_UX_IS_TX_INT(ux)) {
   150  return -ERESTARTSYS;
   151  }
   152  return ux->tx_error;
   153  }
   154  
   155  int usbip_ux_sendmsg(struct usbip_device *ud, struct msghdr *msg, 
   156  struct kvec *vec, size_t num, size_t size)
   157  {
   158  int ret, i, count = 0;
   159  usbip_ux_t *ux;
   160  
   161  usbip_dbg_ux("sendmsg.\n");
   162  rcu_read_lock();
 > 163  ux = rcu_dereference(ud->ux);
   164  if (ux == NULL) {
   165  pr_info("Send to unlinked ux (0).\n");
   166  ret = 0;
   167  goto err_unlock_rcu;
   168  }
   169  ret = usbip_ux_get(ux);
   170  if (ret) {
   171  pr_err("Fail to get ux.\n");

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usbip: fix odd_ptr_err.cocci warnings

[Julia Lawall]

PTR_ERR should access the value just tested by IS_ERR

Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci

CC: Nobuo Iwata 
Signed-off-by: Fengguang Wu 
Signed-off-by: Julia Lawall 
---

I haven't checked the complete context, but the code looks suspicious.

 usbip_ux.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/usbip/usbip_ux.c
+++ b/drivers/usb/usbip/usbip_ux.c
@@ -571,7 +571,7 @@ static int __init usbip_ux_init(void)
usbip_ux_dev = device_create(usbip_ux_class, NULL, usbip_ux_devno, 
NULL, USBIP_UX_DEV_NAME);
if (IS_ERR(usbip_ux_dev)) {
pr_err("Fail to create sysfs entry for %s\n", 
USBIP_UX_DEV_NAME);
-   ret = PTR_ERR(usbip_ux_class);
+   ret = PTR_ERR(usbip_ux_dev);
goto err_cdev_del;
}
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

[Fabio Estevam]

From: Fabio Estevam 

On a mx28 board with a USB hub the following error is observed:

hub 1-1:1.0: USB hub found
hub 1-1:1.0: 2 ports detected
usb 1-1: USB disconnect, device number 2
usb usb1-port1: cannot reset (err = -32)
usb usb1-port1: cannot reset (err = -32)
usb usb1-port1: cannot reset (err = -32)
usb usb1-port1: cannot reset (err = -32)
usb usb1-port1: cannot reset (err = -32)
usb usb1-port1: Cannot enable. Maybe the USB cable is bad?

,which is caused by a problem described by the MXS_PHY_ABNORMAL_IN_SUSPEND
flag.

As we currently do not have a proper implementation for this issue, one
possible workaround is to pass "usbcore.autosuspend=-1" in the kernel
command line, so add this suggestion into the MXS_PHY_ABNORMAL_IN_SUSPEND
flag description.

Signed-off-by: Fabio Estevam 
---
 drivers/usb/phy/phy-mxs-usb.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index c2936dc..453a5ab 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -98,6 +98,10 @@
  * The PHY will be in messy if there is a wakeup after putting
  * bus to suspend (set portsc.suspendM) but before setting PHY to low
  * power mode (set portsc.phcd).
+ *
+ * To work around this problem on mx23/mx28 user should pass
+ * "usbcore.autosuspend=-1" in the kernel command line for now, as
+ * we do not have a proper fix for this flag in the kernel yet.
  */
 #define MXS_PHY_ABNORMAL_IN_SUSPENDBIT(1)
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 RESEND] usb: Use memdup_user to reuse the code

[Pathak, Rahul (R.)]

Hello Greg,

This patch is not yet merged, its already been reviewed and acked by Alan.

Thanks
Rahul

On Thu, Dec 10, 2015 at 09:40:33PM -0800, Rahul Pathak wrote:
> From: Rahul Pathak 
> 
> Fixing coccicheck warning which recommends to use memdup_user instead
> to reimplement its code, using memdup_user simplifies the code
> 
> ./drivers/usb/core/devio.c:1398:11-18: WARNING opportunity for memdup_user
> 
> 
> Signed-off-by: Rahul Pathak 
> 
> ---
> 
> Changes after v1: setting isopkt=NULL for proper kfree() call
> 
> ---
>  drivers/usb/core/devio.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index 38ae877c..844407c 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -1395,11 +1395,10 @@ static int proc_do_submiturb(struct usb_dev_state 
> *ps, struct usbdevfs_urb *uurb
>   number_of_packets = uurb->number_of_packets;
>   isofrmlen = sizeof(struct usbdevfs_iso_packet_desc) *
>  number_of_packets;
> - isopkt = kmalloc(isofrmlen, GFP_KERNEL);
> - if (!isopkt)
> - return -ENOMEM;
> - if (copy_from_user(isopkt, iso_frame_desc, isofrmlen)) {
> - ret = -EFAULT;
> + isopkt = memdup_user(iso_frame_desc, isofrmlen);
> + if (IS_ERR(isopkt)) {
> + ret = PTR_ERR(isopkt);
> + isopkt = NULL;
>   goto error;
>   }
>   for (totlen = u = 0; u < number_of_packets; u++) {
> -- 
> 1.9.1--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html