summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* USB: misc: fixup smatch WARNINGDongjin Kim2013-01-171-4/+5
| | | | | | | | | | | This patch fixes the warning, 6a099c63650e50ebf7d1259b859a3d230aec4207 [4/10] USB: misc: Add USB3503 High-Speed Hub Controller drivers/usb/misc/usb3503.c:238 usb3503_probe() error: we previously assumed 'pdata' could be null (see line 196) Signed-off-by: Dongjin Kim <tobetter@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: misc: usb3503_probe() can be staticFengguang Wu2013-01-171-1/+1
| | | | | Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: ehci-mxc: remove Efika MX-specific CHRGVBUS hackMatt Sealey2013-01-111-20/+0
| | | | | | | | | | | | Since Efika MX platform support (pre-devicetree) was removed from the tree this code no longer has any possibility of running and clutters up the driver which is being replaced by the chipidea host in the future anyway. Signed-off-by: Matt Sealey <matt@genesi-usa.com> Tested-by: Steev Klimazewski <steev@genesi-usa.com> CC: Sascha Hauer <kernel@pengutronix.de> CC: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb/core: update power budget for SuperSpeedSebastian Andrzej Siewior2013-01-112-17/+41
| | | | | | | | | | | | | | | | | | | | | | Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb/core: consider link speed while looking at bMaxPowerSebastian Andrzej Siewior2013-01-116-15/+44
| | | | | | | | | | | | | | | The USB 2.0 specification says that bMaxPower is the maximum power consumption expressed in 2 mA units and the USB 3.0 specification says that it is expressed in 8 mA units. This patch adds a helper function usb_get_max_power() which computes the value based on config & usb_device's speed value. The the device descriptor dump computes the value on its own. Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: ohci: set urb->hcpriv = NULL immediately, after free itChen Gang2013-01-111-0/+1
| | | | | | | | | | although we can not say it is surely a bug. it is better to set urb->hcpriv = NULL, after finish calling urb_free_priv. Signed-off-by: Chen Gang <gang.chen@asianux.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tools/usb: remove unneeded 'continue' and simplify conditionSasha Levin2013-01-111-3/+1
| | | | | | | | | Basically remove unneeded code. Since that 'continue' is at the end of the for() there's no need for it. Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: serial: keyspan: fixed coding style issuesStefan Hubner2013-01-111-2/+2
| | | | | | | fixed coding style issues. Signed-off-by: Stefan Hubner <s.hubner@tilburguniversity.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* uas: fail any request submitted while resetting the device.Gerd Hoffmann2013-01-111-0/+6
| | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* uas: improve device resetGerd Hoffmann2013-01-111-1/+44
| | | | | | | | | | Add new function to unlink and abort requests from the work list, call it on bus reset and disconnect where we kill all in-flight urbs. Also reorder calls in disconnect to first cancel transfers, then remove the scsi hba. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* uas: improve abort handlerGerd Hoffmann2013-01-111-2/+17
| | | | | | | | | | Two changes. First we check whenever the request is linked in the work list and if so take it out. Second check whenever the command is actually in flight before asking the device to cancel it via task management, and in case it isn't just zap the data urbs and finish it. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* uas: add IS_IN_WORK_LIST flagGerd Hoffmann2013-01-111-2/+8
| | | | | | | | Keep track whenever the request is linked into the work list or not. Needed for request abort. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* uas: add UNLINK_DATA_URBS flagGerd Hoffmann2013-01-111-3/+21
| | | | | | | | | uas_unlink_data_urbs uses this to make sure the the scsi command is not released while looking at it. This will be needed when we start calling uas_unlink_data_urbs in the request cancel code paths. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* uas: new function to cancel data urbsGerd Hoffmann2013-01-111-10/+12
| | | | | | | | | | | | Add uas_unlink_data_urbs function to cancel in-flight data urbs. Moves existing code into a separate function. [ v2: also drop the locking, just call usb_unlink_urb no matter what, which is safe because the usb core guarantees the completion callback is called only once ] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: misc: Add USB3503 High-Speed Hub ControllerDongjin Kim2013-01-114-0/+329
| | | | | | | | | | | | This patch adds new driver of SMSC USB3503 USB 2.0 hub controller with HSIC upstream connectivity and three USB 2.0 downstream ports. The specification can be found from 'http://www.smsc.com/index.php?tid=295&pid=325'. The current version have been tested very basic features switching the modes, HUB-MODE and STANDBY-MODE. Signed-off-by: Dongjin Kim <tobetter@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'for-usb-next-2013-01-03' of ↵Greg Kroah-Hartman2013-01-072-102/+107
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next Sarah writes: usb-next: Further warm reset improvements Hi Greg, Here's some patches for 3.9. They further improve the warm reset error handling, but they're too big to go into stable. There's also a patch to remove an unused variable in the xHCI driver. As I mentioned, you'll need to merge usb-linus into usb-next before applying these patches. Sarah Sharp
| * usb: host: xhci: remove unused trb var in xhci_irq()Javier Martinez Canillas2013-01-031-2/+0
| | | | | | | | | | | | | | | | The union xhci_trb *trb variable is defined and assigned inside the xHCI IRQ handler function but is never used. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * USB: Refactor hub_port_wait_reset.Sarah Sharp2013-01-031-36/+37
| | | | | | | | | | | | | | | | | | Refactor hub_port_wait_reset into a small loop to wait for the port reset to be complete, and then a larger block to deal with the final port status. This patch should not change any current behavior. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
| * USB: Use helper function hub_set_port_link_stateSarah Sharp2013-01-031-6/+2
| | | | | | | | | | | | | | | | Change the code that manually issues a Set Port Feature(Link State) to use the new helper function hub_set_port_link_state(). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
| * USB: Fix connected device switch to Inactive state.Sarah Sharp2013-01-031-5/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A USB 3.0 device can transition to the Inactive state if a U1 or U2 exit transition fails. The current code in hub_events simply issues a warm reset, but does not call any pre-reset or post-reset driver methods (or unbind/rebind drivers without them). Therefore the drivers won't know their device has just been reset. hub_events should instead call usb_reset_device. This means hub_port_reset now needs to figure out whether it should issue a warm reset or a hot reset. Remove the FIXME note about needing disconnect() for a NOTATTACHED device. This patch fixes that. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
| * USB: Rip out recursive call on warm port reset.Sarah Sharp2013-01-031-82/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a hot reset fails on a USB 3.0 port, the current port reset code recursively calls hub_port_reset inside hub_port_wait_reset. This isn't ideal, since we should avoid recursive calls in the kernel, and it also doesn't allow us to issue multiple warm resets on reset failures. Rip out the recursive call. Instead, add code to hub_port_reset to issue a warm reset if the hot reset fails, and try multiple warm resets before giving up on the port. In hub_port_wait_reset, remove the recursive call and re-indent. The code is basically the same, except: 1. It bails out early if the port has transitioned to Inactive or Compliance Mode after the reset completed. 2. It doesn't consider a connect status change to be a failed reset. If multiple warm resets needed to be issued, the connect status may have changed, so we need to ignore that and look at the port link state instead. hub_port_reset will now do that. 3. It unconditionally sets udev->speed on all types of successful resets. The old recursive code would set the port speed when the second hub_port_reset returned. The old code did not handle connected devices needing a warm reset well. There were only two situations that the old code handled correctly: an empty port needing a warm reset, and a hot reset that migrated to a warm reset. When an empty port needed a warm reset, hub_port_reset was called with the warm variable set. The code in hub_port_finish_reset would skip telling the USB core and the xHC host that the device was reset, because otherwise that would result in a NULL pointer dereference. When a USB 3.0 device reset migrated to a warm reset, the recursive call made the call stack look like this: hub_port_reset(warm = false) hub_wait_port_reset(warm = false) hub_port_reset(warm = true) hub_wait_port_reset(warm = true) hub_port_finish_reset(warm = true) (return up the call stack to the first wait) hub_port_finish_reset(warm = false) The old code didn't want to notify the USB core or the xHC host of device reset twice, so it only did it in the second call to hub_port_finish_reset, when warm was set to false. This was necessary because before patch two ("USB: Ignore xHCI Reset Device status."), the USB core would pay attention to the xHC Reset Device command error status, and the second call would always fail. Now that we no longer have the recursive call, and warm can change from false to true in hub_port_reset, we need to have hub_port_finish_reset unconditionally notify the USB core and the xHC of the device reset. In hub_port_finish_reset, unconditionally clear the connect status change (CSC) bit for USB 3.0 hubs when the port reset is done. If we had to issue multiple warm resets for a device, that bit may have been set if the device went into SS.Inactive and then was successfully warm reset. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
| * USB: Prepare for refactoring by adding extra udev checks.Sarah Sharp2013-01-031-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | The next patch will refactor the hub port code to rip out the recursive call to hub_port_reset on a failed hot reset. In preparation for that, make sure all code paths can deal with being called with a NULL udev. The usb_device will not be valid if warm reset was issued because a port transitioned to the Inactive or Compliance Mode on a device connect. This patch should have no effect on current behavior. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
| * USB: Don't use EHCI port sempahore for USB 3.0 hubs.Sarah Sharp2013-01-031-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | The EHCI host controller needs to prevent EHCI initialization when the UHCI or OHCI companion controller is in the middle of a port reset. It uses ehci_cf_port_reset_rwsem to do this. USB 3.0 hubs can't be under an EHCI host controller, so it makes no sense to down the semaphore for USB 3.0 hubs. It also makes the warm port reset code more complex. Don't down ehci_cf_port_reset_rwsem for USB 3.0 hubs. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
* | Merge tag 'for-usb-linus-2013-01-03' of ↵Greg Kroah-Hartman2013-01-075-24/+145
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus Sarah says: usb-linus: USB core fixes for warm reset Hi Greg, Happy New Year! Here's some bug fixes for 3.8. I have usb-next patches that are based on this set, so please merge your usb-linus branch into usb-next after this set is applied. The bulk of the patchset (patches 2-7) improve the USB core's warm reset error handling. There's also one patch that fixes an arithmetic error in the xHCI driver, and another to avoid the "dead ports" issue caused by unhandled port status change events. These are all marked for stable. Sarah Sharp
| * xhci: Avoid "dead ports", add roothub port polling.Sarah Sharp2013-01-033-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The USB core hub thread (khubd) is designed with external USB hubs in mind. It expects that if a port status change bit is set, the hub will continue to send a notification through the hub status data transfer. Basically, it expects hub notifications to be level-triggered. The xHCI host controller is designed to be edge-triggered on the logical 'OR' of all the port status change bits. When all port status change bits are clear, and a new change bit is set, the xHC will generate a Port Status Change Event. If another change bit is set in the same port status register before the first bit is cleared, it will not send another event. This means that the hub code may lose port status changes because of race conditions between clearing change bits. The user sees this as a "dead port" that doesn't react to device connects. The fix is to turn on port polling whenever a new change bit is set. Once the USB core issues a hub status request that shows that no change bits are set in any USB ports, turn off port polling. We can't allow the USB core to poll the roothub for port events during host suspend because if the PCI host is in D3cold, the port registers will be all f's. Instead, stop the port polling timer, and unconditionally restart it when the host resumes. If there are no port change bits set after the resume, the first call to hub_status_data will disable polling. This patch should be backported to stable kernels with the first xHCI support, 2.6.31 and newer, that include the commit 0f2a79300a1471cf92ab43af165ea13555c8b0a5 "USB: xhci: Root hub support." There will be merge conflicts because the check for HC_STATE_SUSPENDED was moved into xhci_suspend in 3.8. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
| * USB: Handle warm reset failure on empty port.Sarah Sharp2013-01-031-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An empty port can transition to either Inactive or Compliance Mode if a newly connected USB 3.0 device fails to link train. In that case, we issue a warm reset. Some devices, such as John's Roseweil eusb3 enclosure, slip back into Compliance Mode after the warm reset. The current warm reset code does not check for device connect status on warm reset completion, and it incorrectly reports the warm reset succeeded. This causes the USB core to attempt to send a Set Address control transfer to a port in Compliance Mode, which will always fail. Make hub_port_wait_reset check the current connect status and link state after the warm reset completes. Return a failure status if the device is disconnected or the link state is Compliance Mode or SS.Inactive. Make hub_events disable the port if warm reset fails. This will disable the port, and then bring it back into the RxDetect state. Make the USB core ignore the connect change until the device reconnects. Note that this patch does NOT handle connected devices slipping into the Inactive state very well. This is a concern, because devices can go into the Inactive state on U1/U2 exit failure. However, the fix for that case is too large for stable, so it will be submitted in a separate patch. This patch should be backported to kernels as old as 3.2, contain the commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic" Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: John Covici <covici@ccs.covici.com> Cc: stable@vger.kernel.org
| * USB: Ignore port state until reset completes.Sarah Sharp2013-01-031-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The port reset code bails out early if the current connect status is cleared (device disconnected). If we're issuing a hot reset, it may also look at the link state before the reset is finished. Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the Error state or Resetting state, the port connection bit retains the value from the previous state. Therefore we can't trust it until the reset finishes. Also, the xHCI spec section 4.19.1.2.5 says software shall ignore the link state while the port is resetting, as it can be in an unknown state. The port state during reset is also unknown for USB 2.0 hubs. The hub sends a reset signal by driving the bus into an SE0 state. This overwhelms the "connect" signal from the device, so the port can't tell whether anything is connected or not. Fix the port reset code to ignore the port link state and current connect bit until the reset finishes, and USB_PORT_STAT_RESET is cleared. Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case, because it's redundant. When the warm reset finishes, the port reset bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set. Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit in the code to deal with the finished reset. This patch should be backported to all stable kernels. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
| * USB: Increase reset timeout.Sarah Sharp2013-01-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | John's NEC 0.96 xHCI host controller needs a longer timeout for a warm reset to complete. The logs show it takes 650ms to complete the warm reset, so extend the hub reset timeout to 800ms to be on the safe side. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic". Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: John Covici <covici@ccs.covici.com> Cc: stable@vger.kernel.org
| * USB: Allow USB 3.0 ports to be disabled.Sarah Sharp2013-01-032-4/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If hot and warm reset fails, or a port remains in the Compliance Mode, the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0 ports, once the port is placed into the Disabled link state, it will not report any new device connects. To get device connect notifications, we need to put the link into the Disabled state, and then the RxDetect state. The xHCI driver needs to atomically clear all change bits on USB 3.0 port disable, so that we get Port Status Change Events for future port changes. We could technically do this in the USB core instead of in the xHCI roothub code, since the port state machine can't advance out of the disabled state until we set the link state to RxDetect. However, external USB 3.0 hubs don't need this code. They are level-triggered, not edge-triggered like xHCI, so they will continue to send interrupt events when any change bit is set. Therefore it doesn't make sense to put this code in the USB core. This patch is part of a series to fix several reports of infinite loops on device enumeration failure. This includes John, when he boots with a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96 host controller. The fix requires warm reset support, so it does not make sense to backport this patch to stable kernels without warm reset support. This patch should be backported to kernels as old as 3.2, contain the commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic" Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: John Covici <covici@ccs.covici.com> Cc: stable@vger.kernel.org
| * USB: Ignore xHCI Reset Device status.Sarah Sharp2013-01-031-8/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the USB core finishes reseting a USB device, the xHCI driver sends a Reset Device command to the host. The xHC then updates its internal representation of the USB device to the 'Default' device state. If the device was already in the Default state, the xHC will complete the command with an error status. If a device needs to be reset several times during enumeration, the second reset will always fail because of the xHCI Reset Device command. This can cause issues during enumeration. For example, usb_reset_and_verify_device calls into hub_port_init in a loop. Say that on the first call into hub_port_init, the device is successfully reset, but doesn't respond to several set address control transfers. Then the port will be disabled, but the udev will remain in tact. usb_reset_and_verify_device will call into hub_port_init again. On the second call into hub_port_init, the device will be reset, and the xHCI driver will issue a Reset Device command. This command will fail (because the device is already in the Default state), and usb_reset_and_verify_device will fail. The port will be disabled, and the device won't be able to enumerate. Fix this by ignoring the return value of the HCD reset_device callback. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic". Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
| * USB: Handle auto-transition from hot to warm reset.Sarah Sharp2013-01-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB 3.0 hubs and roothubs will automatically transition a failed hot reset to a warm (BH) reset. In that case, the warm reset change bit will be set, and the link state change bit may also be set. Change hub_port_finish_reset to unconditionally clear those change bits for USB 3.0 hubs. If these bits are not cleared, we may lose port change events from the roothub. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic". Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
| * xhci: Handle HS bulk/ctrl endpoints that don't NAK.Sarah Sharp2013-01-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A high speed control or bulk endpoint may have bInterval set to zero, which means it does not NAK. If bInterval is non-zero, it means the endpoint NAKs at a rate of 2^(bInterval - 1). The xHCI code to compute the NAK interval does not handle the special case of zero properly. The current code unconditionally subtracts one from bInterval and uses it as an exponent. This causes a very large bInterval to be used, and warning messages like these will be printed: usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes This may cause the xHCI host hardware to reject the Configure Endpoint command, which means the HS device will be unusable under xHCI ports. This patch should be backported to kernels as old as 2.6.31, that contain commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval()". Reported-by: Vincent Pelletier <plr.vincent@gmail.com> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
* | Merge tag 'fixes-for-v3.8-rc2' of ↵Greg Kroah-Hartman2013-01-0714-37/+37
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus Felipe says: usb: fixes for v3.8-rc2 Here is the first set of fixes for v3.8-rc cycle. There is a build fix for musb's dsps glue layer caused by some header cleanup on the OMAP tree. Marvel's USB drivers got a fix up for clk API usage switching over to clk_prepare() calls. u_serial has a bug fix for a missing wake_up() which would make gs_cleanup() wait forever for gs_close() to finish. A minor bug fix on dwc3's debugfs interface which would make us read wrong addresses when dumping all registers. dummy_hcd learned how to enumerate g_multi. s3c-hsotg now understands that we shouldn't kfree() memory allocated with devm_*. Other than that, there are a bunch of other minor fixes on renesas_usbhs, tcm_usb_gadget and amd5536udc. All patches have been pending on mailing for many weeks and shouldn't cause any problems.
| * | usb: musb: core: print new line in the driver banner againSergei Shtylyov2012-12-131-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 5c8a86e10a7c164f44537fabdc169fd8b4e7a440 (usb: musb: drop unneeded musb_debug trickery) erroneously removed '\n' from the driver's banner. Concatenate all the banner substrings while adding it back... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: stable@vger.kernel.org # 3.0+ Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: u_serial: fix switch off blockedHaipeng YU2012-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a device is switched off by software, gserial_cleanup will be called, and switch off will be blocked in this function because wake_up_interruptible() in gs_close() can not wake_up the wait_event() in gserial_cleanup(), it should be changed to wake_up() to match the wait_event(). Signed-off-by: Haipeng YU <haipeng.yu@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: tcm_usb_gadge: fix to return error or 0 in tcm_usbg_drop_nexus()Wei Yongjun2012-12-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the error handling case of tcm_usbg_drop_nexus(), the error code is assigned to 'ret', but it is ignored. We'd better return 'ret' instead of always return 0. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: avoid NULL pointer dereference in udc_pci_probe()Xi Wang2012-12-131-2/+2
| | | | | | | | | | | | | | | | | | | | | dev->pdev is NULL before `dev->pdev = pdev'; use pdev instead. Signed-off-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: musb: dsps: header movement build error fixAfzal Mohammed2012-12-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "54db6ee ARM: OMAP2+: Introduce local usb.h" moved control module bit definitions from plat/usb.h (which dsps glue was using) to a local header in mach-omap2. And in parallel, "c68bb4c usb: musb: dsps: control module handling (quirk)" added control module handling capability to dsps glue driver that used those control module bit definitions. Integration of above two changes would cause build error in musb dsps glue driver (they go through different trees upstream) as is seen now in linux-next. Fix it by adding necessary definitions in dsps glue driver. Signed-off-by: Afzal Mohammed <afzal@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: dummy: fix enumeration with g_multiSebastian Andrzej Siewior2012-12-131-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we do have endpoints named like "ep-a" then bEndpointAddress is counted internally by the gadget framework. If we do have endpoints named like "ep-1" then bEndpointAddress is assigned from the digit after "ep-". If we do have both, then it is likely that after we used up the "generic" endpoints we will use the digits and thus assign one bEndpointAddress to multiple endpoints. This theory can be proofed by using the completely enabled g_multi. Without this patch, the mass storage won't enumerate and times out because it shares endpoints with RNDIS. This patch also adds fills up the endpoints list so we have in total endpoints 1 to 15 in + out available while some of them are restricted to certain types like BULK or ISO. Without this change the nokia gadget won't load because the system does not provide enough (BULK) endpoints but it did before ep-a - ep-f were removed. Cc: stable@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: otg: mv_otg: fix the clk APIsChao Xie2012-12-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the clock common driver changes, and arch-mmp will make use of the common clock driver instead of its own. So for enable clock. first prepare the clock then enable the clock. for disable clock first disable the clock then unprepare the clock Signed-off-by: Chao Xie <chao.xie@marvell.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: renesas_usbhs: mod_host: fixup usbhsh_ureq_free() timingKuninori Morimoto2012-12-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | usbhsh_ureq_free() free ureq which includes ubshs_pkt. But current driver used usbhs_pkt after freed ureq. This patch fixup this bug. Special thanks to Chen Reported-by: Chen Gang <gang.chen@asianux.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: renesas_usbhs: gadget: usbhsg_ep_disable() care pipe settingsKuninori Morimoto2012-12-131-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current usbhsg_ep_disable() didn't care uep->pipe and pipe->mod_private variable which is used on usbhsg_ep_enable(). It breaks renesas_usbhs gadget when resume. This patch fixes it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: s3c-hsotg: Fix invalid free of devm_ allocated dataTushar Behera2012-12-131-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since hsotg object is allocated using devm_kzalloc() API, there is no need to free this explicitly. But we need to keep the release API to prevent warnings. Signed-off-by: Tushar Behera <tushar.behera@linaro.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: host: ehci-mv: fix clk APIsChao Xie2012-12-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the clock common driver changes, and arch-mmp will make use of the common clock driver instead of its own. So for enable clock. first prepare the clock then enable the clock. for disable clock first disable the clock then unprepare the clock Signed-off-by: Chao Xie <chao.xie@marvell.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: mv_udc: fix the clk APIsChao Xie2012-12-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the clock common driver changes, and arch-mmp will make use of the common clock driver instead of its own. So for enable clock. first prepare the clock then enable the clock. for disable clock first disable the clock then unprepare the clock Signed-off-by: Chao Xie <chao.xie@marvell.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | USB: fix fsl_otg config dependencyAnatolij Gustschin2012-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB_GADGET_FSL_USB2 has been changed to USB_FSL_USB2 by commit 193ab2a6070039e7ee2b9b9bebea754a7c52fd1b (usb: gadget: allow multiple gadgets to be built). But old USB_GADGET_FSL_USB2 is still listed as dependency for fsl_otg driver, so the driver cannot be selected in the configuration currently. Fix it. Signed-off-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: renesas_usbhs: gadget: remove usbhsg_uep_init()Kuninori Morimoto2012-12-131-10/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current driver always initialized uep->pipe to NULL on usbhsg_try_start(). But it breaks relationship with usb_ep_ops :: enable/disable functions when suspend/resume. This patch solved this issue by initializing uep->pipe on probe() Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: dwc3: debugfs: fix regdump offsetJack Pham2012-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As with dwc_readl/writel, the global registers are specified as offsets starting from the beginning of the xHCI address space, but the memory region pointed to by dwc->regs already maps to the start of the global addresses. Fix by offsetting each of the regs relative to DWC3_GLOBALS_REGS_START. Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
* | | Linux 3.8-rc2v3.8-rc2Linus Torvalds2013-01-021-1/+1
| | |
* | | Merge branch 'fixes-for-3.8' of ↵Linus Torvalds2013-01-021-2/+3
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds Pull LED fix from Bryan Wu. * 'fixes-for-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: leds: leds-gpio: set devm_gpio_request_one() flags param correctly
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-19 17:54:56 +0000