linux-stable.git/include/linux/usb/hcd.h, branch v3.18.4

usb: hcd: add generic PHY support

2014-09-29T15:54:02+00:00

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

usb: rename phy to usb_phy in HCD

2014-09-29T15:52:59+00:00

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

usb: hcd: add TPL support flag

2014-09-24T04:28:41+00:00

The targeted hosts (non-PC hosts) need to have TPL (Targeted Peripheral List)
for USB OTG & EH certification and other vendor specific requirements.

The platform who needs TPL feature should set this flag at usb host
controller driver.

Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

storage: accept some UAS devices if streams are unavailable

2014-03-04T23:41:09+00:00

On some older XHCIs streams are not supported and the UAS driver
will fail at probe time. For those devices storage should try
to bind to UAS devices.
This patch adds a flag for stream support to HCDs and evaluates
it.

[Note: Sarah fixed a bug where the USB 2.0 root hub, not USB 3.0 root
hub would get marked as being able to support streams.]

Signed-off-by: Oliver Neukum 
Signed-off-by: Sarah Sharp 
Acked-by: Hans de Goede

usb: xhci: change enumeration scheme to 'new scheme' by default

2013-12-10T21:54:37+00:00

Change the default enumeration scheme for xhci attached non-SuperSpeed
devices from:

   Reset
   SetAddress [xhci address-device BSR = 0]
   GetDescriptor(8)
   GetDescriptor(18)

...to:

   Reset
   [xhci address-device BSR = 1]
   GetDescriptor(64)
   Reset
   SetAddress [xhci address-device BSR = 0]
   GetDescriptor(18)

...as some devices misbehave when encountering a SetAddress command
prior to GetDescriptor.  There are known legacy devices that require
this scheme, but testing has found at least one USB3 device that fails
enumeration when presented with this ordering.  For now, follow the ehci
case and enable 'new scheme' by default for non-SuperSpeed devices.

To support this enumeration scheme on xhci the AddressDevice operation
needs to be performed twice.  The first instance of the command enables
the HC's device and slot context info for the device, but omits sending
the device a SetAddress command (BSR == block set address request).
Then, after GetDescriptor completes, follow up with the full
AddressDevice+SetAddress operation.

As mentioned before, this ordering of events with USB3 devices causes an
extra state transition to be exposed to xhci.  Previously USB3 devices
would transition directly from 'enabled' to 'addressed' and never need
to underrun responses to 'get descriptor'. We do see the 64-byte
descriptor fetch the correct data, but the following 18-byte descriptor
read after the reset gets:

bLength            = 0
bDescriptorType    = 0
bcdUSB             = 0
bDeviceClass       = 0
bDeviceSubClass    = 0
bDeviceProtocol    = 0
bMaxPacketSize0    = 9

instead of:

bLength            = 12
bDescriptorType    = 1
bcdUSB             = 300
bDeviceClass       = 0
bDeviceSubClass    = 0
bDeviceProtocol    = 0
bMaxPacketSize0    = 9

which results in the discovery process looping until falling back to
'old scheme' enumeration.

Acked-by: Alan Stern 
Reported-by: David Moore 
Suggested-by: Sarah Sharp 
Reported-by: Dan Carpenter 
Signed-off-by: Dan Williams 
Signed-off-by: Sarah Sharp

usb: hcd: Remove USB phy if needed

2013-12-09T02:00:51+00:00

This adds remove_phy flag to the HCD structure. If the flag is
set and if hcd->phy is valid, the phy is shutdown and released
whenever usb_add_hcd fails or usb_hcd_remove is called.
This can be used by the HCD drivers to auto-remove
the external USB phy when it is no longer needed.

Signed-off-by: Valentine Barshak 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

USB: add a private-data pointer to struct usb_tt

2013-10-11T23:45:43+00:00

For improved scheduling of transfers through a Transaction Translator,
ehci-hcd will need to store a bunch of information associated with the
FS/LS bus on the downstream side of the TT.  This patch adds a pointer
for such HCD-private data to the usb_tt structure.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

USB: NS_TO_US should round up

2013-10-11T23:37:45+00:00

Host controller drivers use the NS_TO_US macro to convert transaction
times, which are computed in nanoseconds, to microseconds for
scheduling.  Periodic scheduling requires worst-case estimates, but
the macro does its conversion using round-to-nearest.  This patch
changes it to use round-up, giving a correct worst-case value.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: core: implement AMD remote wakeup quirk

2013-09-26T00:24:37+00:00

The following patch is required to resolve remote wake issues with
certain devices.

Issue description:
If the remote wake is issued from the device in a specific timing
condition while the system is entering sleep state then it may cause
system to auto wake on subsequent sleep cycle.

Root cause:
Host controller rebroadcasts the Resume signal > 100 µseconds after
receiving the original resume event from the device. For proper
function, some devices may require the rebroadcast of resume event
within the USB spec of 100µS.

Workaroud:
1. Filter the AMD platforms with Yangtze chipset, then judge of all the usb
devices are mouse or not. And get out the port id which attached a mouse
with Pixart controller.
2. Then reset the port which attached issue device during system resume
from S3.

[Q] Why the special devices are only mice? Would high speed devices
such as 3G modem or USB Bluetooth adapter trigger this issue?
- Current this sensitivity is only confined to devices that use Pixart
  controllers. This controller is designed for use with LS mouse
devices only. We have not observed any other devices failing. There
may be a small risk for other devices also but this patch (reset
device in resume phase) will cover the cases if required.

[Q] Shouldn’t the resume signal be sent within 100 us for every
device?
- The Host controller may not send the resume signal within 100us,
  this our host controller specification change. This is why we
require the patch to prevent side effects on certain known devices.

[Q] Why would clicking mouse INTENSELY to wake the system up trigger
this issue?
- This behavior is specific to the devices that use Pixart controller.
  It is timing dependent on when the resume event is triggered during
the sleep state.

[Q] Is it a host controller issue or mouse?
- It is the host controller behavior during resume that triggers the
  device incorrect behavior on the next resume.

This patch sets USB_QUIRK_RESET_RESUME flag for these Pixart-based mice
when they attached to platforms with AMD Yangtze chipset.

Signed-off-by: Huang Rui 
Suggested-by: Alan Stern 
Acked-by: Alan Stern 
Acked-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman

USB: see if URB comes from a completion handler

2013-09-17T16:49:24+00:00

Now that URBs can be completed inside tasklets, we need a way of
determining whether a completion handler for a given endpoint is
currently running.  Otherwise it's not possible to maintain the API
guarantee about keeping isochronous streams synchronous when an
underrun occurs.

This patch adds a field and a routine to check whether a completion
handler for a periodic endpoint is running.  At the moment no
analogous routine appears to be necessary for async endpoints, but one
can always be added.

Signed-off-by: Alan Stern 
CC: Ming Lei 
Signed-off-by: Greg Kroah-Hartman