- 24 8月, 2013 1 次提交
-
-
由 Krzysztof Mazur 提交于
If the hub_configure() fails after setting the hdev->maxchild the hub->ports might be NULL or point to uninitialized kzallocated memory causing NULL pointer dereference in hub_quiesce() during cleanup. Now after such error the hdev->maxchild is set to 0 to avoid cleanup of uninitialized ports. Signed-off-by: NKrzysztof Mazur <krzysiek@podlesie.net> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 16 8月, 2013 2 次提交
-
-
由 Lan Tianyu 提交于
The pm qos NO_POWER_OFF flag is checked twice during usb device suspend to see if the usb port power off condition is met. This is redundant and also will prevent the port from being powered off if the NO_POWER_OFF flag is changed to 1 from 0 after the device was already suspended. More detail in the following link. http://marc.info/?l=linux-usb&m=136543949130865&w=2 This patch should be backported to kernels as old as 3.7, that contain the commit f7ac7787 "usb/acpi: Use ACPI methods to power off ports." Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
由 Alan Stern 提交于
The hub driver's usb_port_suspend() routine doesn't handle errors related to Link Power Management properly. It always returns failure, it doesn't try to clean up the wakeup setting, (in the case of system sleep) it doesn't try to go ahead with the port suspend regardless, and it doesn't try to apply the new power-off mechanism. This patch fixes these problems. Note: Sarah fixed this patch to apply against 3.11, since the original commit (4fae6f0f "USB: handle LPM errors during device suspend correctly") called usb_disable_remote_wakeup, which won't be added until 3.12. This patch should be backported to kernels as old as 3.5, that contain the commit 8306095f "USB: Disable USB 3.0 LPM in critical sections.". There will be merge conflicts, since LTM wasn't added until 3.6. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
- 03 8月, 2013 1 次提交
-
-
由 Yacine Belkadi 提交于
When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: NYacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 01 8月, 2013 5 次提交
-
-
由 Alan Stern 提交于
The hub driver's usb_port_suspend() routine doesn't handle errors related to Link Power Management properly. It always returns failure, it doesn't try to clean up the wakeup setting, (in the case of system sleep) it doesn't try to go ahead with the port suspend regardless, and it doesn't try to apply the new power-off mechanism. This patch fixes these problems. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
This patch simplifies the interface presented by usb_get_status(). Instead of forcing callers to check for the proper data length and convert the status value to host byte order, the function will now do these things itself. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Julius Werner 提交于
The USB hub driver's event handler contains a check to catch SuperSpeed devices that transitioned into the SS.Inactive state and tries to fix them with a reset. It decides whether to do a plain hub port reset or call the usb_reset_device() function based on whether there was a device attached to the port. However, there are device/hub combinations (found with a JetFlash Transcend mass storage stick (8564:1000) on the root hub of an Intel LynxPoint PCH) which can transition to the SS.Inactive state on disconnect (and stay there long enough for the host to notice). In this case, above-mentioned reset check will call usb_reset_device() on the stale device data structure. The kernel will send pointless LPM control messages to the no longer connected device address and can even cause several 5 second khubd stalls on some (buggy?) host controllers, before finally accepting the device's fate amongst a flurry of error messages. This patch makes the choice of reset dependent on the port status that has just been read from the hub in addition to the existence of an in-kernel data structure for the device, and only proceeds with the more extensive reset if both are valid. Signed-off-by: NJulius Werner <jwerner@chromium.org> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Julius Werner 提交于
The USB hub driver's event handler contains a check to catch SuperSpeed devices that transitioned into the SS.Inactive state and tries to fix them with a reset. It decides whether to do a plain hub port reset or call the usb_reset_device() function based on whether there was a device attached to the port. However, there are device/hub combinations (found with a JetFlash Transcend mass storage stick (8564:1000) on the root hub of an Intel LynxPoint PCH) which can transition to the SS.Inactive state on disconnect (and stay there long enough for the host to notice). In this case, above-mentioned reset check will call usb_reset_device() on the stale device data structure. The kernel will send pointless LPM control messages to the no longer connected device address and can even cause several 5 second khubd stalls on some (buggy?) host controllers, before finally accepting the device's fate amongst a flurry of error messages. This patch makes the choice of reset dependent on the port status that has just been read from the hub in addition to the existence of an in-kernel data structure for the device, and only proceeds with the more extensive reset if both are valid. Signed-off-by: NJulius Werner <jwerner@chromium.org> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
- 26 7月, 2013 2 次提交
-
-
由 Alan Stern 提交于
This patch removes a redundant nested "#ifdef CONFIG_PM" from the hub driver. It also adds a label to the "#endif" line corresponding to the outer "#ifdef CONFIG_PM". Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 William Gulland 提交于
Control transfers have both IN and OUT (or SETUP) packets, so when clearing TT buffers for a control transfer it's necessary to send two HUB_CLEAR_TT_BUFFER requests to the hub. Signed-off-by: NWilliam Gulland <wgulland@google.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 17 7月, 2013 1 次提交
-
-
由 Alan Stern 提交于
The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: NToralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 6月, 2013 1 次提交
-
-
由 Mathias Nyman 提交于
usb_hub_to_struct_hub() can return NULL in some unlikely cases. Add checks where appropriate, or pass the hub pointer as an additional argument if it's known to be valid. The places it makes sense to check usb_hub_to_struct_hub() are picked based on feedback from Alan Stern. Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 29 3月, 2013 3 次提交
-
-
由 Alan Stern 提交于
This patch (as1675) removes the CONFIG_USB_SUSPEND option, essentially replacing it everywhere with CONFIG_PM_RUNTIME (except for one place in hub.c, where it is replaced with CONFIG_PM because the code needs to be used in both runtime and system PM). The net result is code shrinkage and simplification. There's very little point in keeping CONFIG_USB_SUSPEND because almost everybody enables it. The few that don't will find that the usbcore module has gotten somewhat bigger and they will have to take active measures if they want to prevent hubs from being runtime suspended. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
This patch (as1674) speeds up system sleep transitions by not suspending each individual device on a USB-1.1 or USB-2 bus. The devices will automatically go into suspend when their root hubs are suspended (i.e., stop sending out Start-Of-Frame packets) -- this is what the USB spec calls "global suspend". Since this is what we do already when CONFIG_USB_SUSPEND isn't enabled, it shouldn't cause any problems. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Tested-by: NJenya Y <jy.gerstmaier@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 26 3月, 2013 1 次提交
-
-
由 David Linares 提交于
Return an error if hub->descriptor->bNbrPorts==0. Without this additional check, we can end up doing a "hub->ports = kzalloc(0, GFP_KERNEL)". This hub->ports pointer will therefore be non-NULL and will be used. Example of dmesg: INIT: usb 1-1: New USB device found, idVendor=0424, idProduct=2512 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-1:1.0: USB hub found version 2.86 bootinghub 1-1:1.0: 0 ports detected Unable to handle kernel NULL pointer dereference at virtual address 00000010 Signed-off-by: NDavid Linares <dlinares.linux@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 24 2月, 2013 1 次提交
-
-
由 Ming Lei 提交于
If one storage interface or usb network interface(iSCSI case) exists in current configuration, memory allocation with GFP_KERNEL during usb_device_reset() might trigger I/O transfer on the storage interface itself and cause deadlock because the 'us->dev_mutex' is held in .pre_reset() and the storage interface can't do I/O transfer when the reset is triggered by other interface, or the error handling can't be completed if the reset is triggered by the storage itself (error handling path). Signed-off-by: NMing Lei <ming.lei@canonical.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: David Decotigny <david.decotigny@google.com> Cc: Tom Herbert <therbert@google.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Jens Axboe <axboe@kernel.dk> Cc: Minchan Kim <minchan@kernel.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.de> Reviewed-by: NJiri Kosina <jkosina@suse.cz> Cc: Mel Gorman <mel@csn.ul.ie> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Greg KH <greg@kroah.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 26 1月, 2013 2 次提交
-
-
由 Lan Tianyu 提交于
This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: NAlan Stern <stern@rowland.harvard.edu> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Lan Tianyu 提交于
This patch is to add runtime pm callback for usb port device. Set/clear PORT_POWER feature in the resume/suspend callback. Add portnum for struct usb_port to record port number. Do pm_rumtime_get_sync/put(portdev) when a device is plugged/unplugged to prevent it from being powered off when it is active. Acked-by: NAlan Stern <stern@rowland.harvard.edu> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 25 1月, 2013 1 次提交
-
-
由 Lan Tianyu 提交于
Usb3.0 device defines function remote wakeup which is only for interface recipient rather than device recipient. This is different with usb2.0 device's remote wakeup feature which is defined for device recipient. According usb3.0 spec 9.4.5, the function remote wakeup can be modified by the SetFeature() requests using the FUNCTION_SUSPEND feature selector. This patch is to use correct way to disable usb3.0 device's function remote wakeup after suspend error and resuming. This should be backported to kernels as old as 3.4, that contain the commit 623bef9e "USB/xhci: Enable remote wakeup for USB3 devices." Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
- 22 1月, 2013 1 次提交
-
-
由 Lan Tianyu 提交于
ACPI provide "_PLD" and "_UPC" aml methods to describe usb port visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable() to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in the rh_call_control(). When hub descriptor request is issued at first time, usb port device isn't created and usb port is not bound with acpi. So first hub descriptor request is not changed based on ACPI information. After usb port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure() and then set hub port's DeviceRemovable according ACPI information and this also works for non-root hub. Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 1月, 2013 1 次提交
-
-
由 Lan Tianyu 提交于
To show the relationship between usb port and child device, add link file "port" under usb device's sysfs directoy and "device" under usb port device's sysfs directory. They are linked to each other. Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 1月, 2013 1 次提交
-
-
由 Lan Tianyu 提交于
This patch is to create driver/usb/core/(port.c,hub.h) files and move usb port related code into port.c. Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 12 1月, 2013 3 次提交
-
-
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: NAlan Stern <stern@rowland.harvard.edu> Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Oliver Neukum 提交于
Some touchscreens have buggy firmware which claims remote wakeup to be enabled after a reset. They nevertheless crash if the feature is cleared by the host. Add a check for reset resume before checking for an enabled remote wakeup feature. On compliant devices the feature must be cleared after a reset anyway. Signed-off-by: NOliver Neukum <oneukum@suse.de> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 1月, 2013 12 次提交
-
-
由 Sarah Sharp 提交于
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: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu>
-
由 Sarah Sharp 提交于
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: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu>
-
由 Sarah Sharp 提交于
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: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu>
-
由 Sarah Sharp 提交于
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: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu>
-
由 Sarah Sharp 提交于
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: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu>
-
由 Sarah Sharp 提交于
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: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu>
-
由 Sarah Sharp 提交于
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 75d7cf72 "usbcore: refine warm reset logic" Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Reported-by: NJohn Covici <covici@ccs.covici.com> Cc: stable@vger.kernel.org
-
由 Sarah Sharp 提交于
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: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
-
由 Sarah Sharp 提交于
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 75d7cf72 "usbcore: refine warm reset logic". Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Reported-by: NJohn Covici <covici@ccs.covici.com> Cc: stable@vger.kernel.org
-
由 Sarah Sharp 提交于
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 75d7cf72 "usbcore: refine warm reset logic" Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Reported-by: NJohn Covici <covici@ccs.covici.com> Cc: stable@vger.kernel.org
-
由 Sarah Sharp 提交于
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 75d7cf72 "usbcore: refine warm reset logic". Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
-
由 Sarah Sharp 提交于
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 75d7cf72 "usbcore: refine warm reset logic". Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
-
- 16 11月, 2012 1 次提交
-
-
由 Peter Chen 提交于
The old parameter "port" is useless for phy notify, as one usb phy is only for one usb port. New parameter "speed" stands for the device's speed which is on the port, this "speed" parameter is needed at some platforms which will do some phy operations according to device's speed. Signed-off-by: NPeter Chen <peter.chen@freescale.com> Tested-by: NMike Thompson <mpthompson@gmail.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-