linux/drivers/usb, branch v3.9

USB / PM: Don't try to hide PM QoS flags from usb_port_device_release()

2013-04-01T23:25:09Z

Remove the call to dev_pm_qos_hide_flags(), added by commit 6e30d7cb "usb: Add driver/usb/core/(port.c,hub.h) files", from usb_port_device_release(), because (1) it is completely unnecessary (the flags have been removed already by the PM core during the unregistration of the device object) and (2) it triggers a NULL pointer dereference in sysfs_find_dirent() (dev->kobj.sd is NULL at this point). Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman

usb: ftdi_sio: Add support for Mitsubishi FX-USB-AW/-BD

2013-03-28T15:50:22Z

It enhances the driver for FTDI-based USB serial adapters to recognize Mitsubishi Electric Corp. USB/RS422 Converters as FT232BM chips and support them. https://search.meau.com/?q=FX-USB-AW Signed-off-by: Konstantin Holoborodko Tested-by: Konstantin Holoborodko Cc: stable Signed-off-by: Greg Kroah-Hartman

usb: Fix compile error by selecting USB_OTG_UTILS

2013-03-27T15:49:20Z

The current lpc32xx_defconfig breaks like this, caused by recent phy restructuring: LD init/built-in.o drivers/built-in.o: In function `usb_hcd_nxp_probe': drivers/usb/host/ohci-nxp.c:224: undefined reference to `isp1301_get_client' drivers/built-in.o: In function `lpc32xx_udc_probe': drivers/usb/gadget/lpc32xx_udc.c:3104: undefined reference to `isp1301_get_client' distcc[27867] ERROR: compile (null) on localhost failed make: *** [vmlinux] Error 1 Caused by 1c2088812f095df77f4b3224b65db79d7111a300 (usb: Makefile: fix drivers/usb/phy/ Makefile entry) This patch fixes this by selecting USB_OTG_UTILS in Kconfig which causes the phy driver to be built again. Signed-off-by: Roland Stigge Acked-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

Merge tag 'for-usb-linus-2013-03-26' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus

2013-03-26T21:14:54Z

Misc xHCI fixes for 3.9 Hi Greg, Here's a couple of fixes for the xHCI driver. Three patches are nothing major: build warning fix, macro field width fix, and removing some unnecessary log spam. The only interesting thing here is Tianyu's two patches to fix the USB port connection type discovery, for the USB port power off mechanism. This adds new USB host API, but as discussed, it's necessary to avoid powering off the wrong USB port. It's not marked for backport to stable kernels, since the sysfs mechanism to manually power off a port didn't go in until 3.9. I've smoke tested these, including system suspend, USB device suspend, and rocking out in my cube with a pair of USB headphones. They look fine to me. Hibernate is currently broken on my system, due to some nouveau MMIO read faults. I'll report that separately. Sarah Sharp

USB: serial: fix hang when opening port

2013-03-26T16:28:29Z

Johan's 'fix use-after-free in TIOCMIWAIT' patchset[1] introduces one bug which can cause kernel hang when opening port. This patch initialized the 'port->delta_msr_wait' waitqueue head to fix the bug which is introduced in 3.9-rc4. [1], http://marc.info/?l=linux-usb&m=136368139627876&w=2 Cc: stable Signed-off-by: Ming Lei Acked-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

USB: EHCI: fix bug in iTD/siTD DMA pool allocation

2013-03-25T20:59:04Z

[Description written by Alan Stern] Soeren tracked down a very difficult bug in ehci-hcd's DMA pool management of iTD and siTD structures. Some background: ehci-hcd gives each isochronous endpoint its own set of active and free itd's (or sitd's for full-speed devices). When a new itd is needed, it is taken from the head of the free list, if possible. However, itd's must not be used twice in a single frame because the hardware continues to access the data structure for the entire duration of a frame. Therefore if the itd at the head of the free list has its "frame" member equal to the current value of ehci->now_frame, it cannot be reused and instead a new itd is allocated from the DMA pool. The entries on the free list are not released back to the pool until the endpoint is no longer in use. The bug arises from the fact that sometimes an itd can be moved back onto the free list before itd->frame has been set properly. In Soeren's case, this happened because ehci-hcd can allocate one more itd than it actually needs for an URB; the extra itd may or may not be required depending on how the transfer aligns with a frame boundary. For example, an URB with 8 isochronous packets will cause two itd's to be allocated. If the URB is scheduled to start in microframe 3 of frame N then it will require both itds: one for microframes 3 - 7 of frame N and one for microframes 0 - 2 of frame N+1. But if the URB had been scheduled to start in microframe 0 then it would require only the first itd, which could cover microframes 0 - 7 of frame N. The second itd would be returned to the end of the free list. The itd allocation routine initializes the entire structure to 0, so the extra itd ends up on the free list with itd->frame set to 0 instead of a meaningful value. After a while the itd reaches the head of the list, and occasionally this happens when ehci->now_frame is equal to 0. Then, even though it would be okay to reuse this itd, the driver thinks it must get another itd from the DMA pool. For as long as the isochronous endpoint remains in use, this flaw in the mechanism causes more and more itd's to be taken slowly from the DMA pool. Since none are released back, the pool eventually becomes exhausted. This reuslts in memory allocation failures, which typically show up during a long-running audio stream. Video might suffer the same effect. The fix is very simple. To prevent allocations from the pool when they aren't needed, make sure that itd's sent back to the free list prematurely have itd->frame set to an invalid value which can never be equal to ehci->now_frame. This should be applied to -stable kernels going back to 3.6. Signed-off-by: Soeren Moch Signed-off-by: Alan Stern Cc: stable Signed-off-by: Greg Kroah-Hartman

xhci: Don't warn on empty ring for suspended devices.

2013-03-25T17:39:19Z

When a device attached to the roothub is suspended, the endpoint rings are stopped. The host may generate a completion event with the completion code set to 'Stopped' or 'Stopped Invalid' when the ring is halted. The current xHCI code prints a warning in that case, which can be really annoying if the USB device is coming into and out of suspend. Remove the unnecessary warning. Signed-off-by: Sarah Sharp Tested-by: Stephen Hemminger

usb: xhci: Fix TRB transfer length macro used for Event TRB.

2013-03-25T17:39:18Z

Use proper macro while extracting TRB transfer length from Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23) for the same, and use it instead of TRB_LEN (bits 0:16) in case of event TRBs. This patch should be backported to kernels as old as 2.6.31, that contain the commit b10de142119a676552df3f0d2e3a9d647036c26a "USB: xhci: Bulk transfer support". This patch will have issues applying to older kernels. Signed-off-by: Vivek gautam Signed-off-by: Sarah Sharp Cc: stable@vger.kernel.org

usb/acpi: binding xhci root hub usb port with ACPI

2013-03-25T17:39:17Z

This patch is to bind xhci root hub usb port with its acpi node. The port num in the acpi table matches with the sequence in the xhci extended capabilities table. So call usb_hcd_find_raw_port_number() to transfer hub port num into raw port number which associates with the sequence in the xhci extended capabilities table before binding. Signed-off-by: Lan Tianyu Signed-off-by: Sarah Sharp

usb: add find_raw_port_number callback to struct hc_driver()

2013-03-25T17:39:17Z

xhci driver divides the root hub into two logical hubs which work respectively for usb 2.0 and usb 3.0 devices. They are independent devices in the usb core. But in the ACPI table, it's one device node and all usb2.0 and usb3.0 ports are under it. Binding usb port with its acpi node needs the raw port number which is reflected in the xhci extended capabilities table. This patch is to add find_raw_port_number callback to struct hc_driver(), fill it with xhci_find_raw_port_number() which will return raw port number and add a wrap usb_hcd_find_raw_port_number(). Otherwise, refactor xhci_find_real_port_number(). Using xhci_find_raw_port_number() to get real index in the HW port status registers instead of scanning through the xHCI roothub port array. This can help to speed up. All addresses in xhci->usb2_ports and xhci->usb3_ports array are kown good ports and don't include following bad ports in the extended capabilities talbe. (1) root port that doesn't have an entry (2) root port with unknown speed (3) root port that is listed twice and with different speeds. So xhci_find_raw_port_number() will only return port num of good ones and never touch bad ports above. Signed-off-by: Lan Tianyu Signed-off-by: Sarah Sharp