29 Sep, 2014
4 commits
-
Add the generic PHY support, analogous to the USB PHY support. Intended it to be
used with the PCI EHCI/OHCI drivers and the xHCI platform driver.Signed-off-by: Sergei Shtylyov
Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Greg Kroah-Hartman -
The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
This is in preparation to adding the generic PHY support.Signed-off-by: Antoine Tenart
[Sergei: added missing 'drivers/usb/misc/lvstest.c' file, resolved rejects,
updated changelog.]
Signed-off-by: Sergei Shtylyov
Acked-by: Alan Stern
Acked-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
The current code only returns -ENOTSUPP for OTG host, but in fact,
embedded host also needs to returns -ENOTSUPP if the peripheral
is not at TPL.Signed-off-by: Peter Chen
Signed-off-by: Greg Kroah-Hartman -
Commit 0cce2eda19923e5e5ccc8b042dec5af87b3ffad0
USB: fix LANGID=0 regressiondefaults to a langid of 0x0409 if it's not properly implemented by the
device. Explain with a higher level error message what this means.Signed-off-by: Scot Doyle
Signed-off-by: Greg Kroah-Hartman
25 Sep, 2014
1 commit
-
With this patch, USB activity can be signaled by blinking a LED. There
are two triggers, one for activity on USB host and one for USB gadget.Both triggers should work with all host/device controllers. Tested only
with musb.Performace: I measured performance overheads on ARM Cortex-A8 (TI
AM335x) running on 600 MHz.Duration of usb_led_activity():
- with no LED attached to the trigger: 2 ± 1 µs
- with one GPIO LED attached to the trigger: 2 ± 1 µs or 8 ± 2 µs (two peaks in histogram)Duration of functions calling usb_led_activity() (with this patch
applied and no LED attached to the trigger):
- __usb_hcd_giveback_urb(): 10 - 25 µs
- usb_gadget_giveback_request(): 2 - 6 µsSigned-off-by: Michal Sojka
Acked-by: Felipe Balbi
Tested-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman
24 Sep, 2014
12 commits
-
It seems that only choose_devnum() was not ready to process more hub
events at the same time.All should be fine if we take bus->usb_address0_mutex there. It will
make sure that more devnums will not be chosen for the given bus and
the related devices at the same time.Signed-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
USB hub has started to use a workqueue instead of kthread. Let's update
the documentation and comments here and there.This patch mostly just replaces "khubd" with "hub_wq". There are only few
exceptions where the whole sentence was updated. These more complicated
changes can be found in the following files:Documentation/usb/hotplug.txt
drivers/net/usb/usbnet.c
drivers/usb/core/hcd.c
drivers/usb/host/ohci-hcd.c
drivers/usb/host/xhci.cSigned-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
USB hub started to use a workqueue instead of kthread. Let's make it clear from
the function names.Signed-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
There is no need to have separate kthread for handling USB hub events.
It is more elegant to use the workqueue framework.The workqueue is allocated as freezable because the original thread was
freezable as well.Also it is allocated as ordered because the code is not ready for parallel
processing of hub events, see choose_devnum().struct usb_hub is passed via the work item. Therefore we do not need
hub_event_list.Also hub_thread() is not longer needed. It would call only hub_event().
The rest of the code did manipulate the kthread and it is handled by the
workqueue framework now.kick_khubd is renamed to kick_hub_wq() to make the function clear. And the
protection against races is done another way, see below.hub_event_lock has been removed. It cannot longer be used to protect struct
usb_hub between hub_event() and hub_disconnect(). Instead we need to get
hub->kref already in kick_hub_wq().The lock is not really needed for the other scenarios as well. queue_work()
returns whether it succeeded. We could revert the needed operations
accordingly. This is enough to avoid duplicity and inconsistencies.Yes, the removed lock causes that there is not longer such a strong
synchronization between scheduling the work and manipulating
hub->disconnected.But kick_hub_wq() must never be called together with hub_disconnect()
otherwise even the original code would have failed. Any callers are
responsible for this.Therefore the only problem is that hub_disconnect() could be called in parallel
with hub_event(). But this was possible even in the past. struct usb_hub is
still guarded by hub->kref and released in hub_events() when needed.Note that the source file is still full of the obsolete "khubd" strings.
Let's remove them in a follow up patch. This patch already is complex enough.Thanks a lot Alan Stern for code review, many useful
tips and guidance. Also thanks to Tejun Heo for hints how to
allocate the workqueue.Signed-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
We would like to convert khubd kthread to a workqueue. As a result hub_events()
will handle only one event per call.In fact, we could do this already now because there is another cycle in
hub_thread(). It calls hub_events() until hub_event_list is empty.This patch renames the function to hub_event(), removes the while cycle, and
renames the goto targets from loop* to out*.When touching the code, it fixes also formatting of dev_err() and dev_dbg()
calls to make checkpatch.pl happy :-)Signed-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This is just a small optimization of the fix from the commit c605f3cdff53a743f6
("usb: hub: take hub->hdev reference when processing from eventlist).We do not need to take the reference for each event. Instead we could get it
when struct usb_hub is allocated and put it when it is released. By other words,
we could handle it the same way as the reference for hub->intfdev.The motivation is that it will make the life easier when switching from khubd
kthread to a workqueue.Suggested-by: Alan Stern
Signed-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This full-speed USB device generates spurious remote wakeup event
as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result,
Linux can't enter system suspend and S0ix power saving modes once
this keyboard is used.This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk.
With this quirk set, wakeup capability will be ignored during
device configure.This patch could be back-ported to kernels as old as 2.6.39.
Signed-off-by: Lu Baolu
Acked-by: Alan Stern
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
Fixed typos in comments of various drivers/usb files
Signed-off-by: Mickael Maison
Acked-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
Update configuration for USB_OTG_WHITELIST, any targeted hosts
(non PC-hosts) can have TPL (Targered Peripheral List).Signed-off-by: Peter Chen
Signed-off-by: Greg Kroah-Hartman -
According to On-The-Go and Embedded Host Supplement to the USB Revision
2.0 Specification, the targeted hosts (non-PC hosts) include both
embedded hosts and otg, and each targeted host product defines the
set of supported peripherals on a TPL (Targeted Peripheral List). So,
TPL should apply for both OTG and embedded host, and the otg support is
not a must for embedded host.The TPL support feature will only be effect when CONFIG_USB_OTG_WHITELIST
has been chosen and hcd->tpl_support flag is set, it can avoid the enumeration
fails problem for the user who chooses CONFIG_USB_OTG_WHITELIST wrongly.Signed-off-by: Peter Chen
Signed-off-by: Greg Kroah-Hartman -
Enable device-qualifier quirk for Elan Touchscreen, which often fails to
handle requests for the device_descriptor.Note that the device sometimes do respond properly with a Request Error
(three times as USB core retries), but usually fails to respond at all.
When this happens any further descriptor requests also fails, for
example:[ 1528.688934] usb 2-7: new full-speed USB device number 4 using xhci_hcd
[ 1530.945588] usb 2-7: unable to read config index 0 descriptor/start: -71
[ 1530.945592] usb 2-7: can't read configurations, error -71This has been observed repeating for over a minute before eventual
successful enumeration.Reported-by: Drew Von Spreecken
Reported-by: Greg Kroah-Hartman
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
Add new quirk for devices that cannot handle requests for the
device_qualifier descriptor.A USB-2.0 compliant device must respond to requests for the
device_qualifier descriptor (even if it's with a request error), but at
least one device is known to misbehave after such a request.Suggested-by: Bjørn Mork
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
11 Sep, 2014
1 commit
-
During surprise device hotplug removal tests, it was observed that
hub_events may try to call usb_lock_device on a device that has already
been freed. Protect the usb_device by taking out a reference (under the
hub_event_lock) when hub_events pulls it off the list, returning the
reference after hub_events is finished using it.Signed-off-by: Joe Lawrence
Suggested-by: David Bulkow for using kref
Suggested-by: Alan Stern for placement
Acked-by: Alan Stern
Cc: stable
Signed-off-by: Greg Kroah-Hartman
28 Aug, 2014
1 commit
-
commit bdd405d2a528 ("usb: hub: Prevent hub autosuspend if
usbcore.autosuspend is -1") causes a build error if CONFIG_PM_RUNTIME is
disabled. Fix that by doing a simple #ifdef guard around it.Reported-by: Stephen Rothwell
Reported-by: kbuild test robot
Cc: Roger Quadros
Cc: Michael Welling
Cc: Alan Stern
Signed-off-by: Greg Kroah-Hartman
27 Aug, 2014
1 commit
-
If user specifies that USB autosuspend must be disabled by module
parameter "usbcore.autosuspend=-1" then we must prevent
autosuspend of USB hub devices as well.commit 596d789a211d introduced in v3.8 changed the original behaivour
and stopped respecting the usbcore.autosuspend parameter for hubs.Fixes: 596d789a211d "USB: set hub's default autosuspend delay as 0"
Cc: [3.8+]
Signed-off-by: Roger Quadros
Tested-by: Michael Welling
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
20 Aug, 2014
2 commits
-
linux-2.6/drivers/usb/core/hub.c: In function 'usb_disconnect':
linux-2.6/drivers/usb/core/hub.c:2110: warning: 'hub' may be used uninitialized in this function
linux-2.6/drivers/usb/core/hub.c:2111: warning: 'port1' may be used uninitialized in this functionSigned-off-by: Peter Chen
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce
failures of the same port] added the check of the reliable port, but
it also replaced the device argument to dev_err() wrongly, which leads
to a NULL dereference.This patch restores the right device, port_dev->dev. Also, since
dev_err() itself shows the port number, reduce the port number shown
in the error message, essentially reverting to the state before the
commit 5ee0f803cc3a.[The fix suggested by Hannes, and the error message cleanup suggested
by Alan Stern]Fixes: 5ee0f803cc3a ('usbcore: don't log on consecutive debounce failures of the same port')
Reported-by: Hannes Reinecke
Cc:
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
05 Aug, 2014
1 commit
-
Pull USB updates from Greg KH:
"Here is the big USB driver update for 3.17-rc1.Loads of gadget driver changes in here, including some big file
movements to make things easier to manage over time. There's also the
usual xhci and uas driver updates, and a handful of other changes in
here. The changelog has the full details.All of these have been in linux-next for a while"
* tag 'usb-3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (211 commits)
USB: devio: fix issue with log flooding
uas: Log a warning when we cannot use uas because the hcd lacks streams
uas: Only complain about missing sg if all other checks succeed
xhci: Add missing checks for xhci_alloc_command failure
xhci: Rename Asrock P67 pci product-id to EJ168
xhci: Blacklist using streams on the Etron EJ168 controller
uas: Limit qdepth to 32 when connected over usb-2
uwb/whci: use correct structure type name in sizeof
usb-core bInterval quirk
USB: serial: ftdi_sio: Add support for new Xsens devices
USB: serial: ftdi_sio: Annotate the current Xsens PID assignments
usb: chipidea: debug: fix sparse non static symbol warnings
usb: ci_hdrc_imx doc: fsl,usbphy is required
usb: ci_hdrc_imx: Return -EINVAL for missing USB PHY
usb: core: allow zero packet flag for interrupt urbs
usb: lvstest: Fix sparse warnings generated by kbuild test bot
USB: core: hcd-pci: free IRQ before disabling PCI device when shutting down
phy: miphy365x: Represent each PHY channel as a DT subnode
phy: miphy365x: Provide support for the MiPHY356x Generic PHY
phy: miphy365x: Add Device Tree bindings for the MiPHY365x
...
02 Aug, 2014
2 commits
-
usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK
for output URBs. That causes usbcore to log messages without limit
for a nonsensical disallowed combination. The fix is to silently drop
the attribute in usbfs.
The problem is reported to exist since 3.14
https://www.virtualbox.org/ticket/13085Signed-off-by: Oliver Neukum
CC: stable@vger.kernel.org
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch adds a usb quirk to support devices with interupt endpoints
and bInterval values expressed as microframes. The quirk causes the
parse endpoint function to modify the reported bInterval to a standards
conforming value.There is currently code in the endpoint parser that checks for
bIntervals that are outside of the valid range (1-16 for USB 2+ high
speed and super speed interupt endpoints). In this case, the code assumes
the bInterval is being reported in 1ms frames. As well, the correction
is only applied if the original bInterval value is out of the 1-16 range.With this quirk applied to the device, the bInterval will be
accurately adjusted from microframes to an exponent.Signed-off-by: James P Michels III
Signed-off-by: Greg Kroah-Hartman
23 Jul, 2014
2 commits
-
Section 4.4.7.2 "Interrupt Transfer Bandwidth Requirements" of the USB3.0 spec
says:
A zero-length data payload is a valid transfer and may be useful for
some implementations.So, extend the logic of allowing URB_ZERO_PACKET to interrupt urbs too.
Otherwise, the kernel throws warning of BOGUS transfer flags.Signed-off-by: Amit Virdi
Acked-by: Hans de Goede
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
The assigned IRQ should be freed before calling pci_disable_device()
when shutting down system, otherwise it will cause following warning.
[ 568.879482] ------------[ cut here ]------------
[ 568.884236] WARNING: CPU: 1 PID: 3300 at /home/konrad/ssd/konrad/xtt-i386/bootstrap/linux-usb/fs/proc/generic.c:521 remove_proc_entry+0x165/0x170()
[ 568.897846] remove_proc_entry: removing non-empty directory 'irq/16', leaking at least 'ohci_hcd:usb4'
[ 568.907430] Modules linked in: dm_multipath dm_mod iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c_generic sg sd_mod crct10dif_generic crc_t10dif crct10dif_common radeon fbcon tileblit ttm font bitblit softcursor ata_generic ahci libahci drm_kms_helper skge r8169 libata mii scsi_mod wmi acpi_cpufreq
[ 568.938539] CPU: 1 PID: 3300 Comm: init Tainted: G W 3.16.0-rc5upstream-01651-g03b9189 #1
[ 568.947946] Hardware name: ECS A780GM-A Ultra/A780GM-A Ultra, BIOS 080015 04/01/2010
[ 568.956008] 00000209 ed0f1cd0 c1617946 c175403c ed0f1d00 c1090c3f c1754084 ed0f1d2c
[ 568.964068] 00000ce4 c175403c 00000209 c11f22a5 c11f22a5 f755e8c0 ed0f1d78 f755e90d
[ 568.972128] ed0f1d18 c1090cde 00000009 ed0f1d10 c1754084 ed0f1d2c ed0f1d60 c11f22a5
[ 568.980194] Call Trace:
[ 568.982715] [] dump_stack+0x48/0x60
[ 568.987294] [] warn_slowpath_common+0x7f/0xa0
[ 569.003887] [] warn_slowpath_fmt+0x2e/0x30
[ 569.009092] [] remove_proc_entry+0x165/0x170
[ 569.014476] [] unregister_irq_proc+0xaa/0xc0
[ 569.019858] [] free_desc+0x1f/0x60
[ 569.024346] [] irq_free_descs+0x3a/0x80
[ 569.029283] [] irq_dispose_mapping+0x2d/0x50
[ 569.034666] [] mp_unmap_irq+0x73/0xa0
[ 569.039423] [] acpi_unregister_gsi_ioapic+0x2b/0x40
[ 569.045431] [] acpi_unregister_gsi+0xf/0x20
[ 569.050725] [] acpi_pci_irq_disable+0x4b/0x50
[ 569.056196] [] pcibios_disable_device+0x18/0x20
[ 569.061848] [] do_pci_disable_device+0x4d/0x60
[ 569.067410] [] pci_disable_device+0x47/0xb0
[ 569.077814] [] usb_hcd_pci_shutdown+0x31/0x40
[ 569.083285] [] pci_device_shutdown+0x19/0x50
[ 569.088667] [] device_shutdown+0x14/0x120
[ 569.093777] [] kernel_restart_prepare+0x2d/0x30
[ 569.099429] [] kernel_restart+0xe/0x60
[ 569.109028] [] SYSC_reboot+0x191/0x220
[ 569.159269] [] SyS_reboot+0x1a/0x20
[ 569.163843] [] sysenter_do_call+0x12/0x16
[ 569.168951] ---[ end trace ccc1ec4471c289c9 ]---Tested-by: Aaron Lu
Signed-off-by: Jiang Liu
Reviewed-by: Huang Rui
Signed-off-by: Greg Kroah-Hartman
19 Jul, 2014
3 commits
-
Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
take longer time for link training compared to many others. Such
devices fail to reconnect with same old address which was associated
with it before suspend.When system resumes, at some point of time (dpm_run_callback->
usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
usb_port_resume) SW reads hub status. If device is present,
then it finishes port resume and re-enumerates device with same
address. If device is not present then, SW thinks that device was
removed during suspend and therefore does logical disconnection
and removes all the resource allocated for this device.Now, if I put sufficient delay just before root hub status read in
usb_resume_device then, SW sees always that device is present. In normal
course(without any delay) SW sees that no device is present and then SW
removes all resource associated with the device at this port. In the
latter case, after sometime, device says that hey I am here, now host
enumerates it, but with new address.Problem had been reproduced when I connect verbatim USB3.0 hard disc
with my STiH407 XHCI host running with 3.10 kernel.I see that similar problem has been reported here.
https://bugzilla.kernel.org/show_bug.cgi?id=53211
Reading above it seems that bug was not in 3.6.6 and was present in 3.8
and again it was not present for some in 3.12.6, while it was present
for few others. I tested with 3.13-FC19 running at i686 desktop, problem
was still there. However, I was failed to reproduce it with 3.16-RC4
running at same i686 machine. I would say it is just a random
observation. Problem for few devices is always there, as I am unable to
find a proper fix for the issue.So, now question is what should be the amount of delay so that host is
always able to recognize suspended device after resume.XHCI specs 4.19.4 says that when Link training is successful, port sets
CSC bit to 1. So if SW reads port status before successful link
training, then it will not find device to be present. USB Analyzer log
with such buggy devices show that in some cases device switch on the
RX termination after long delay of host enabling the VBUS. In few other
cases it has been seen that device fails to negotiate link training in
first attempt. It has been reported till now that few devices take as
long as 2000 ms to train the link after host enabling its VBUS and
RX termination. This patch implements a 2000 ms timeout for CSC bit to set
ie for link training. If in a case link trains before timeout, loop will
exit earlier.This patch implements above delay, but only for SS device and when
persist is enabled.So, for the good device overhead is almost none. While for the bad
devices penalty could be the time which it take for link training.
But, If a device was connected before suspend, and was removed
while system was asleep, then the penalty would be the timeout ie
2000 ms.Results:
Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
Kernel resumes in 461 msecs without this patch, but hard disk is
assigned a new device address. Same system resumes in 790 msecs with
this patch, but with old device address.Cc:
Signed-off-by: Pratyush Anand
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
I am removing two fix mes in this file as after dicussing then it seems
there is no reason to check against Null for usb_device as it can never
be NULL and this is check is therefore not needed.Signed-off-by: Nicholas Krause
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
Some laptops have an internal port for a BT device which picks
up noise when the kill switch is used, but not enough to trigger
printk_rlimit(). So we shouldn't log consecutive faults of this kind.Signed-off-by: Oliver Neukum
Cc: stable
Signed-off-by: Greg Kroah-Hartman
18 Jul, 2014
3 commits
-
When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
[1022:7814], the second hotplugging will experience the USB 3.0 pen
drive is recognized as high-speed device. After bisecting the kernel,
I found the commit number 41e7e056cdc662f704fa9262e5c6e213b4ab45dd
(USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing
some experiments, the bug can be fixed by avoiding executing the function
hub_usb3_port_disable(). Because the port status with [AMD] FCH USB
XHCI Controlleris [1022:7814] is already in RxDetect
(I tried printing out the port status before setting to Disabled state),
it's reasonable to check the port status before really executing
hub_usb3_port_disable().Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.)
Signed-off-by: Gavin Guo
Acked-by: Alan Stern
Cc:
Signed-off-by: Greg Kroah-Hartman -
usb_alloc_dev is used by lvstest driver now which can be built as
module. Therefore export usb_alloc_dev symbol.Signed-off-by: Pratyush Anand
Signed-off-by: Greg Kroah-Hartman -
When a host controller dies, we don't need to wait for a driver to
time out. We can shut down its URBs immediately. Without this
change, we can end up waiting 30 seconds for a mass-storage transfer
to time out.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
12 Jul, 2014
1 commit
-
The usb device will autoresume from choose_wakeup() if it is
autosuspended with the wrong wakeup setting, but below errors occur
because usb3503 misc driver will switch to standby mode when suspended.As add USB_QUIRK_RESET_RESUME, it can stop setting wrong wakeup from
autosuspend_check().[ 7.734717] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[ 7.854658] usb 1-3: device descriptor read/64, error -71
[ 8.079657] usb 1-3: device descriptor read/64, error -71
[ 8.294664] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[ 8.414658] usb 1-3: device descriptor read/64, error -71
[ 8.639657] usb 1-3: device descriptor read/64, error -71
[ 8.854667] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[ 9.264598] usb 1-3: device not accepting address 3, error -71
[ 9.374655] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[ 9.784601] usb 1-3: device not accepting address 3, error -71
[ 9.784838] usb usb1-port3: device 1-3 not suspended yetSigned-off-by: Joonyoung Shim
Signed-off-by: Greg Kroah-Hartman
10 Jul, 2014
2 commits
-
Resuming a powered down port sometimes results in the port state being
stuck in the training sequence.hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
port1: can't get reconnection after setting port power on, status -110
hub 3-0:1.0: port 1 status 0000.02e0 after resume, -19
usb 3-1: can't resume, status -19
hub 3-0:1.0: logical disconnect on port 1In the case above we wait for the port re-connect timeout of 2 seconds
and observe that the port status is USB_SS_PORT_LS_POLLING (although it
is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT).
This is indicative of a case where the device is failing to progress the
link training state machine.It is resolved by issuing a warm reset to get the hub and device link
state machines back in sync.hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
usb usb3: port1 usb_port_runtime_resume requires warm reset
hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms
usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcdAfter a reconnect timeout when we expect the device to be present, force
a warm reset of the device. Note that we can not simply look at the
link status to determine if a warm reset is required as any of the
training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or
USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need
for warm reset by themselves.Cc: Alan Stern
Cc: Kukjin Kim
Cc: Vincent Palatin
Cc: Lan Tianyu
Cc: Ksenia Ragiadakou
Cc: Vivek Gautam
Cc: Douglas Anderson
Cc: Felipe Balbi
Cc: Sunil Joshi
Cc: Hans de Goede
Acked-by: Julius Werner
Signed-off-by: Dan Williams
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
When a USB device is disconnected, usb_unbind_interface is called, which
tries to enable and disable LPM. usb_enable_lpm also try to send a
control command SET SEL to the device.
Since device is already disconnected, therefore it does not make sense
to execute usb_(en/dis)able_lpm.
This patch returns from usb_(en/dis)able_lpm, if device was not in
default state atleast.Signed-off-by: Pratyush Anand
Tested-by: Aymen Bouattay
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
18 Jun, 2014
4 commits
-
Commit 9262c19d14c4 "usb: disable port power control if not supported in
wHubCharacteristics" gated enabling runtime pm for usb_port devices on
whether the parent hub supports power control, which causes a
regression. The port must still be allowed to carry out runtime pm
callbacks and receive a -EAGAIN or -EBUSY result. Otherwise the
usb_port device will transition to the pm error state and trigger the
same for the child usb_device.Prior to the offending commit usb_hub_create_port_device() arranged for
runtime pm to be disabled is dev_pm_qos_expose_flags() failed. Instead,
force the default state of PM_QOS_FLAG_NO_POWER_OFF flag to be set prior
to enabling runtime pm. If that policy can not be set then fail
registration.Report: http://marc.info/?l=linux-usb&m=140290586301336&w=2
Fixes: 9262c19d14c4 ("usb: disable port power control if not supported in wHubCharacteristics")
Reported-by: Bjørn Mork
Reported-by: Alan Stern
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
In the case where platform firmware has specified conflicting values for
port locations it is confusing and otherwise not helpful to throw a
backtrace. Instead, include enough information to determine that
firmware has done something wrong and globally disable port poweroff.Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
Reading through a recent bug report [1], Alan notes:
"Dan, the warning message in hub_suspend() should mention that the
child device isn't suspended yet."...update the warning from:
"usb usb3-port4: not suspended yet"
...to:
"usb usb3-port4: device 3-4: not suspended yet"
[1]: http://marc.info/?l=linux-usb&m=140290586301336&w=2
Reported-by: Alan Stern
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
Commit d8521afe3586 "usb: assign default peer ports for root hubs"
delayed marking a hub valid (set hdev->maxchild) until it had been fully
configured and to enable the publishing of valid hubs to be serialized
by usb_port_peer_mutex.However, xhci_update_hub_device() in some cases depends on
hdev->maxchild already being set. Do the minimal fix and move it after
the setting of hdev->maxchild.Cc: Mathias Nyman
Reported-by: Valdis Kletnieks
Tested-by: Valdis Kletnieks
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman