Alan Stern | 30 Jun 17:25 2015

[PATCH] USB: OHCI: Fix race between ED unlink and URB submission

This patch fixes a bug introduced by commit 977dcfdc6031 ("USB: OHCI:
don't lose track of EDs when a controller dies").  The commit changed
ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had
been called.  The user-visible consequence is that the driver
occasionally crashes or locks up when an URB is submitted while
another URB for the same endpoint is being unlinked.

This patch moves the ED state change later, to the right place.  The
drawback is that now we may unnecessarily execute some instructions
multiple times when a controller dies.  Since controllers dying is an
exceptional occurrence, a little wasted time won't matter.

Signed-off-by: Alan Stern <stern@...>
Reported-by: Heiko Przybyl <lil_tux@...>
Tested-by: Heiko Przybyl <lil_tux@...>
Fixes: 977dcfdc60311e7aa571cabf6f39c36dde13339e
CC: <stable@...>



 drivers/usb/host/ohci-q.c |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

Index: usb-4.0/drivers/usb/host/ohci-q.c
--- usb-4.0.orig/drivers/usb/host/ohci-q.c
+++ usb-4.0/drivers/usb/host/ohci-q.c
 <at>  <at>  -980,10 +980,6  <at>  <at>  rescan_all:
(Continue reading)

Oliver Neukum | 30 Jun 16:45 2015

self-modeswitching device


I am looking at a device that spontaneously switches
its mode. I guess that you need to actively do something
that some Windows versions do to keep the device in its
initial mode.
The device contains an SD card reader. That leaves me in
a predicament. The medium if it is mounted before the
device switches will be dirty.

Normally we say that unmounting before you switch
is a responsibility of user space. But this device
switches by itself.
In that particular case I would go as far as make
the storage driver refuse the storage interface
of the initial mode.

What do you think?


To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at

Kris Borer | 30 Jun 15:02 2015

[PATCH] usb: move assignment out of if condition

Fix four occurrences of the error:

ERROR: do not use assignment in if condition

Signed-off-by: Kris Borer <kborer@...>
 drivers/usb/core/hcd.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index be5b207..e268c45 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
 <at>  <at>  -2683,12 +2683,13  <at>  <at>  int usb_add_hcd(struct usb_hcd *hcd,
 	 * bottom up so that hcds can customize the root hubs before hub_wq
 	 * starts talking to them.  (Note, bus id is assigned early too.)
-	if ((retval = hcd_buffer_create(hcd)) != 0) {
+	retval = hcd_buffer_create(hcd);
+	if (retval != 0) {
 		dev_dbg(hcd->self.controller, "pool alloc failed\n");
 		goto err_create_buf;
-	if ((retval = usb_register_bus(&hcd->self)) < 0)
+	retval = usb_register_bus(&hcd->self);
+	if (retval < 0)
 		goto err_register_bus;

 	rhdev = usb_alloc_dev(NULL, &hcd->self, 0);
(Continue reading)

AMAN DEEP | 30 Jun 14:10 2015

[EDT][PATCH] USB XHCI: Bugfix for NULL pointer deference in xhci_endpoint_init() function


virt_dev->num_cached_rings counts on freed ring and 
is not updated correctly. In xhci_free_or_cache_endpoint_ring() function, 
the free ring is added into cache and then 
num_rings_cache is incremented as below:
		virt_dev->ring_cache[rings_cached] =
here, free ring pointer is added to a current index and then 
index is incremented.
So current index always points to empty location in the ring cache.
For getting available free ring, 
current index should be decremented first and then
corresponding ring buffer value should be taken from ring cache.

But In function xhci_endpoint_init(), 
the num_rings_cached index is accessed before decrement.
		virt_dev->eps[ep_index].new_ring =
		virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
This is bug in manipulating the index of ring cache.
And it should be as below:
		virt_dev->eps[ep_index].new_ring =
		virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;

Signed-off-by: Aman Deep <aman.deep <at>>
(Continue reading)

Peter Chen | 30 Jun 09:47 2015

About zero-length packet design for EHCI

Hi Alan,

When reading the code (at qh_urb_transaction) about zero-length packet
for EHCI, would you please help me on below questions:

- I have not found the zero-length qtd prepared for control read (eg,
the transfer size is multiple of wMaxPacketSize), Am I missing

- Why the IN transfer doesn't need to prepare zero-length qtd?
In the 2.0 spec, it does not say it is only for OUT.

Ch 5.7.3 & Ch 5.8.3
A bulk (interrupt) transfer is complete when the endpoint does one of the following:
- Has transferred exactly the amount of data expected
- Transfers a packet with a payload size less than wMaxPacketSize or
transfers a zero-length packet

Ch 5.6.4
An isochronous IN endpoint must return a zero-length packet whenever
data is requested at a faster interval
than the specified interval and data is not available.




Best Regards,
Peter Chen
(Continue reading)

Qatar Foundation | 30 Jun 06:04 2015

Claim €950,000.00 EURO

Lieber Begünstigte,

Sie wurden ausgewählt, um € 950.000,00 EURO als Charity-Spenden / Hilfe der Qatar Foundation
erhalten. Antworten zurück für weitere Informationen.

Mit freundlichen Grüßen,
Ingenieur Saad Al Muhannadi.
Beantworten: qfoundation63@...

Präsident der Qatar Foundation.

Dear Beneficiary,

You have been selected to receive €950,000.00 EURO as charity donations / aid of the Qatar Foundation.
Reply back for more information.

Yours sincerely,
Engineer Saad Al Muhannadi.
Reply to: qfoundation63@...

President of the Qatar Foundation.

This email has been checked for viruses by Avast antivirus software.

To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at
(Continue reading)

Glasswall Information Point | 30 Jun 08:53 2015

Re: [Bug 100631] Usb device not functioning in initramfs luks disk unlock

Op 29-06-15 om 19:01 schreef bugzilla-daemon@...:
> --- Comment #1 from Greg Kroah-Hartman <greg@...> ---
> On Mon, Jun 29, 2015 at 09:53:04AM +0000, bugzilla-daemon@...
> wrote:
>>             Bug ID: 100631
>>            Summary: Usb device not functioning in initramfs luks disk
>>                     unlock
> Please send to the linux-usb@... mailing list.
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at

Peter Chen | 30 Jun 04:23 2015

Re: Official bugreport 4.1 kernel (audio gadget and ChipIdea)

On Fri, Jun 26, 2015 at 07:15:18PM +0200, Sébastien Pruvost wrote:
> Hello,
> I'm sending this mail to report a bug concerning the latest kernel 4.1.
> Here is the problem (and the test I've done):
>                 I have firstly used the 3.10.53 kernel for my two sabrelites in
> order to use the audio gadget driver with the Dual Role ChipIdea Controller (in
> order to switch roles between my two IMX6 sabreLite).
> After loading g_audio in my two sabreLite and plugging the cable (microA –
> microB), there is an error “ci_hdrc.0 request length too big for isochronous
> snd_uac2.0 1116 Error”.
> And even after running aplay command, I still got this error and there is no
> sound getting out of the jack port.
> I've switched roles between the two boards by following this: https://
> This works fine with the serial driver, I can see a new serial interface (host
> side) and after switching role a new serial interfaces at device side. Same
> thing for ethernet gadget: this works fine too. But not with the audio gadget.
> In fact, there is a new audio interface at host side but I can not interact
> with it (even alsamixer doesn’t see any controls on this new sound card). I’ve
> tested that audio gadget works fine if I don’t use ChipIdea HighSpeed Dual Role
> Controller.
>                 Secondly I have tested this audio gadget with the latest Kernel
> 4.1 for my two IMX6 sabrelites (imx_v6_v7_defconfig). Now these previous errors
> are gone but there are still no sound getting out of the jack port (even if
(Continue reading)

Felipe Balbi | 30 Jun 03:18 2015

[PATCH] usb: dwc2: gadget: use | instead of + for bitmasks

It's just a lot clearer to use | operator instead of
+ operator.

Caught by coccicheck:

	drivers/usb/dwc2/gadget.c:2883:26-27: WARNING: sum of probable
	bitmasks, consider |

Cc: John Youn <John.Youn@...>
Signed-off-by: Felipe Balbi <balbi@...>
 drivers/usb/dwc2/gadget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 4d47b7c09238..731b13dfc512 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
 <at>  <at>  -2880,7 +2880,7  <at>  <at>  static int s3c_hsotg_ep_sethalt(struct usb_ep *ep, int value)
 		epctl = readl(hs->regs + epreg);

 		if (value) {
 			if (epctl & DXEPCTL_EPENA)
 				epctl |= DXEPCTL_EPDIS;
 		} else {

(Continue reading)

Raphael Hertzog | 29 Jun 14:13 2015

USB disks not recognized during boot

[ Please keep me in CC as I'm not subscribed ]


I'm the happy owner of a Intel NUC D54250WYKH (updated it to latest Intel
firmware) which has an XHCI host controller. It's connected over USB 3 to
a JBOD-configured disk enclosure (ICYBOX IB-RD3640SU3E2) which uses a
JMicron USB to ATA bridge. I have attached the output of lspci -v, lsusb
-v, lshw to describe the hardware in more details.

When I boot the computer, the disk enclosure is not detected/recognized
(even though it's correctly powered up). I have to power cycle the disk
enclosure while the NUC is running so that it gets properly detected
(see dmesg-powercycle). The kernel messages do not show any obvious error
during boot (see attached file dmesg-boot)

I have this problem with the stock 4.1 kernel as well as all Debian kernels
(3.16.x in Jessie, 4.0.x in Stretch).

While googling for possible solutions to force a new detection of the
hardware, I found the explanation of how to unbind/rebind the xhci_hcd

echo -n "0000:00:14.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
echo -n "0000:00:14.0" > /sys/bus/pci/drivers/xhci_hcd/bind

(with "0000:00:14.0" the PCI identifier of the xHCI root hub)

This does not work for me. The undetected disk enclosure stays
unnoticed... only the hardware power cycle works.
(Continue reading)

Oliver Neukum | 29 Jun 11:10 2015

[PATCH] usbhid: no flushing if device is already polled

From: Oliver Neukum <oneukum@...>

During open() it is unnecessary to wait for the device to flush
stale inputs if the device is polled while closed due to a quirk
or opening fails.

Signed-off-by: Oliver Neukum <oneukum@...>
 drivers/hid/usbhid/hid-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 63d1f0f..54dec35 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
 <at>  <at>  -710,7 +710,8  <at>  <at>  int usbhid_open(struct hid_device *hid)
 		 * Wait 50 msec for the queue to empty before allowing events
 		 * to go through hid.
-		msleep(50);
+		if (res == 0 && !(hid->quirks & HID_QUIRK_ALWAYS_POLL))
+			msleep(50);
 		clear_bit(HID_RESUME_RUNNING, &usbhid->iofl);


To unsubscribe from this list: send the line "unsubscribe linux-usb" in
(Continue reading)