linux-toradex.git/drivers/usb/core, branch v3.17-rc4

USB: fix build error with CONFIG_PM_RUNTIME disabled

2014-08-27T23:55:29+00:00

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

usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1

2014-08-26T22:59:14+00:00

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

usb: core: fix below build warning

2014-08-19T16:28:53+00:00

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 function

Signed-off-by: Peter Chen 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usbcore: Fix wrong device in an error message in hub_port_connect()

2014-08-19T16:16:08+00:00

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

Merge tag 'usb-3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

2014-08-05T03:11:28+00:00

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
  ...

USB: devio: fix issue with log flooding

2014-08-01T23:01:46+00:00

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/13085

Signed-off-by: Oliver Neukum 
CC: stable@vger.kernel.org
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb-core bInterval quirk

2014-08-01T22:47:05+00:00

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

usb: core: allow zero packet flag for interrupt urbs

2014-07-22T23:30:58+00:00

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

USB: core: hcd-pci: free IRQ before disabling PCI device when shutting down

2014-07-22T23:30:58+00:00

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

USB: Fix persist resume of some SS USB devices

2014-07-18T23:18:11+00:00

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