linux/drivers/usb, branch v2.6.39

drivercore: revert addition of of_match to struct device

2011-05-18T18:32:23Z

Commit b826291c, "drivercore/dt: add a match table pointer to struct device" added an of_match pointer to struct device to cache the of_match_table entry discovered at driver match time. This was unsafe because matching is not an atomic operation with probing a driver. If two or more drivers are attempted to be matched to a driver at the same time, then the cached matching entry pointer could get overwritten. This patch reverts the of_match cache pointer and reworks all users to call of_match_device() directly instead. Signed-off-by: Grant Likely

xHCI: Clear PLC in xhci_bus_resume()

2011-05-03T18:14:32Z

This patch clears PORT_PLC if xhci_bus_resume() resumes a previous suspended port, because if a port transition from U3 to U0 state, it will report a port link state change, and software should clear the corresponding PLC bit. It also uses hcd->speed to check if a port is a USB2 protocol port. The patch fixes the issue that USB keyboard can not wakeup system from hibernation. Signed-off-by: Andiry Xu Signed-off-by: Sarah Sharp

usb/isp1760: Report correct urb status after unlink

2011-05-03T00:07:49Z

This fixes a bug in my previous (2.6.38) patch series which caused urb->status value to be wrong after unlink (broke usbtest 11, 12). Signed-off-by: Arvid Brodin Signed-off-by: Greg Kroah-Hartman

omap:usb: add regulator support for EHCI

2011-05-02T12:29:26Z

in case of ehci phy mode; regulator of phy should be enabled before initializing the usbhs core driver. Signed-off-by: Keshava Munegowda Tested-by: Steve Calfee Signed-off-by: Felipe Balbi

usb: musb: gadget: Fix out-of-sync runtime pm calls

2011-05-02T09:34:33Z

If cable is not connected to peripheral only board when initializing the gadget driver, then runtime pm calls are out-of-sync and the musb cannot idle with omap2430.c. This was noted on Nokia N900 where musb prevented the CPU to be able to enter deeper retention idle state. This was working in 2.6.38 before runtime pm conversions but there musb smart standby/idle modes were configured statically where they are now updated runtime depending on use and cable status. Reason for out-of-sync is that runtime pm is activated in function musb_gadget.c: usb_gadget_probe_driver but suspended only in OTG mode if cable is not connected when initializing. In peripheral only mode this leads to out-of-sync runtime pm since runtime pm remain active and is activated another time in omap2430.c: musb_otg_notifications for VBUS Connect event and thus cannot suspend for VBUS Disconnect event since the use count remains active. Fix this by moving cable status check and pm_runtime_put call in usb_gadget_probe_driver out of is_otg_enabled block. Signed-off-by: Jarkko Nikula Signed-off-by: Felipe Balbi

usb: musb: omap2430: Fix retention idle on musb peripheral only boards

2011-05-02T09:34:32Z

Recent runtime pm and hwmod conversions for 2.6.39 broke the musb peripheral mode OMAP retention idle on boards where the board mode in struct musb_hdrc_platform_data is set to MUSB_PERIPHERAL. These conversions changed the way how the OTG_SYSCONFIG register is configured and used in runtime. Before 2.6.39 smart standby/idle modes were activated statically in OTG_SYSCONFIG. Those modes allow that the musb is able to idle when peripheral device is not connected to host. In 2.6.39 the OTG_SYSCONFIG is updated runtime depending on VBUS status. No standby/idle modes are used when device is connected and force standby/idle when disconnected. Unfortunately VBUS disconnect event that handles the disconnect case lets the peripheral musb to idle only when board mode is MUSB_OTG. Fix this by checking the peripheral mode also. Signed-off-by: Jarkko Nikula Signed-off-by: Felipe Balbi

Revert "USB: isp1760-hcd: move imask clear after pending work is done"

2011-04-14T20:37:07Z

This reverts commit 5808544690300071f09eef9ab83a0fb1f60cf1cd. To quote Richard: I don't think this should be mainlined. It was a misunderstanding on my part. If you see all the other hdc drivers in the same location, they all do the same thing (i.e. clear the interrupt status first, then do the work) that "glitch" I think I saw was actually two back-to-back interrupts. Sebastian (the original author of isp1760) explained it to me a few days after my submission. sorry for the confusion Cc: Richard Retanubun Signed-off-by: Greg Kroah-Hartman

xHCI: Implement AMD PLL quirk

2011-04-13T23:57:37Z

This patch disable the optional PM feature inside the Hudson3 platform under the following conditions: 1. If an isochronous device is connected to xHCI port and is active; 2. Optional PM feature that powers down the internal Bus PLL when the link is in low power state is enabled. The PM feature needs to be disabled to eliminate PLL startup delays when the link comes out of low power state. The performance of DMA data transfer could be impacted if system delay were encountered and in addition to the PLL start up delays. Disabling the PM would leave room for unpredictable system delays in order to guarantee uninterrupted data transfer to isochronous audio or video stream devices that require time sensitive information. If data in an audio/video stream was interrupted then erratic audio or video performance may be encountered. AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the quirk code to pci-quirks.c and export them, xHCI driver can call it directly without having the quirk implementation in itself. Signed-off-by: Andiry Xu Signed-off-by: Sarah Sharp

xhci: Tell USB core both roothubs lost power.

2011-04-13T23:57:36Z

On a resume, when the power is lost during hibernate, the USB core will call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB 3.0 roothub: [ 164.748310] usb usb1: root hub lost power or was reset [ 164.748353] usb usb2: root hub lost power or was reset [ 164.748487] usb usb3: root hub lost power or was reset [ 164.748488] xhci_hcd 0000:01:00.0: Stop HCD ... [ 164.870039] hub 4-0:1.0: hub_resume ... [ 164.870054] hub 3-0:1.0: hub_reset_resume This causes issues later, because the USB core assumes the USB 3.0 hub attached to the USB 3.0 roothub is still active. It attempts to queue a control URB for the external hub, which fails because all the device slot contexts were released when the USB 3.0 roothub lost power: [ 164.980044] hub 4-1:1.0: hub_resume [ 164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101 [ 164.980049] xHCI xhci_urb_enqueue called with unaddressed device [ 164.980053] hub 3-0:1.0: port 1: status 0101 change 0001 [ 164.980056] hub 4-1:1.0: hub_port_status failed (err = -22) [ 164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90008948440, 32'h202e1, 4'hf); [ 164.980062] xHCI xhci_urb_enqueue called with unaddressed device [ 164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual port 0 status = 0x2e1 [ 164.980069] hub 4-1:1.0: hub_port_status failed (err = -22) [ 164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 status = 0x2a0 [ 164.980074] xHCI xhci_urb_enqueue called with unaddressed device [ 164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100 [ 164.980079] hub 4-1:1.0: hub_port_status failed (err = -22) [ 164.980082] xHCI xhci_urb_enqueue called with unaddressed device [ 164.980085] hub 4-1:1.0: hub_port_status failed (err = -22) [ 164.980088] hub 4-1:1.0: port 4: status 0000 change 0000 [ 164.980091] xHCI xhci_urb_enqueue called with unaddressed device [ 164.980094] hub 4-1:1.0: activate --> -22 [ 164.980113] xHCI xhci_urb_enqueue called with unaddressed device [ 164.980117] hub 4-1:1.0: hub_port_status failed (err = -22) [ 164.980119] xHCI xhci_urb_enqueue called with unaddressed device [ 164.980123] hub 4-1:1.0: can't resume port 4, status -22 [ 164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22 [ 164.980129] usb 4-1.4: can't resume, status -22 [ 164.980131] hub 4-1:1.0: logical disconnect on port 4 This causes issues when a USB 3.0 hard drive is attached to the external USB 3.0 hub when the system is hibernated: [ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code [ 6249.849659] sd 8:0:0:0: [sdb] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 02 00 [ 6249.849671] end_request: I/O error, dev sdb, sector 10760 Make sure to inform the USB core that *both* xHCI roothubs lost power. Signed-off-by: Sarah Sharp

usbcore: Bug fix: system can't suspend with USB3.0 device connected to USB3.0 hub

2011-04-13T23:57:34Z

This patch clear PORT_POWER when suspend a USB3.0 device behind a USB3.0 external hub, so the system can suspend and resume. Note USB3.0 device may not work after system resume and this is a temporary workaround. The correct fix will be in future patches. Signed-off-by: Andiry Xu Signed-off-by: Sarah Sharp