linux-toradex.git/include/linux/usb/hcd.h, branch v3.2.73

USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd)

2015-05-09T22:16:14+00:00

commit 074f9dd55f9cab1b82690ed7e44bcf38b9616ce0 upstream.

Currently the USB stack assumes that all host controller drivers are
capable of receiving wakeup requests from downstream devices.
However, this isn't true for the isp1760-hcd driver, which means that
it isn't safe to do a runtime suspend of any device attached to a
root-hub port if the device requires wakeup.

This patch adds a "cant_recv_wakeups" flag to the usb_hcd structure
and sets the flag in isp1760-hcd.  The core is modified to prevent a
direct child of the root hub from being put into runtime suspend with
wakeup enabled if the flag is set.

Signed-off-by: Alan Stern 
Tested-by: Nicolas Pitre 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN

2015-05-09T22:16:12+00:00

commit 5efd2ea8c9f4f12916ffc8ba636792ce052f6911 upstream.

the following error pops up during "testusb -a -t 10"
| musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,	f134e000/be842000 (bad dma)
hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
hcd_buffer_alloc() returning memory which is 32 bytes aligned and it
might by identified by buffer_offset() as another buffer. This means the
buffer which is on a 32 byte boundary will not get freed, instead it
tries to free another buffer with the error message.

This patch fixes the issue by creating the smallest DMA buffer with the
size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is
smaller). This might be 32, 64 or even 128 bytes. The next three pools
will have the size 128, 512 and 2048.
In case the smallest pool is 128 bytes then we have only three pools
instead of four (and zero the first entry in the array).
The last pool size is always 2048 bytes which is the assumed PAGE_SIZE /
2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where
we would end up with 8KiB buffer in case we have 16KiB pages.
Instead I think it makes sense to have a common size(s) and extend them
if there is need to.
There is a BUILD_BUG_ON() now in case someone has a minalign of more than
128 bytes.

Signed-off-by: Sebastian Andrzej Siewior 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

USB: fix build error when CONFIG_PM_SLEEP isn't enabled

2013-10-26T20:06:00+00:00

commit 9d8924297cd9c256c23c02abae40202563452453 upstream.

This patch fixes a build error that occurs when CONFIG_PM is enabled
and CONFIG_PM_SLEEP isn't:

>> drivers/usb/host/ohci-pci.c:294:10: error: 'usb_hcd_pci_pm_ops' undeclared here (not in a function)
      .pm = &usb_hcd_pci_pm_ops

Since the usb_hcd_pci_pm_ops structure is defined and used when
CONFIG_PM is enabled, its declaration should not be protected by
CONFIG_PM_SLEEP.

Signed-off-by: Alan Stern 
Reported-by: kbuild test robot 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

USB: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2

2012-06-19T22:18:25+00:00

commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b upstream.

This patch (as1558) fixes a problem affecting several ASUS computers:
The machine crashes or corrupts memory when going into suspend if the
ehci-hcd driver is bound to any controllers.  Users have been forced
to unbind or unload ehci-hcd before putting their systems to sleep.

After extensive testing, it was determined that the machines don't
like going into suspend when any EHCI controllers are in the PCI D3
power state.  Presumably this is a firmware bug, but there's nothing
we can do about it except to avoid putting the controllers in D3
during system sleep.

The patch adds a new flag to indicate whether the problem is present,
and avoids changing the controller's power state if the flag is set.
Runtime suspend is unaffected; this matters only for system suspend.
However as a side effect, the controller will not respond to remote
wakeup requests while the system is asleep.  Hence USB wakeup is not
functional -- but of course, this is already true in the current state
of affairs.

A similar patch has already been applied as commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers).  The patch supersedes that one and reverts
it.  There are two differences:

	The old patch added the flag at the USB level; this patch
	adds it at the PCI level.

	The old patch applied to all chipsets with the same vendor,
	subsystem vendor, and product IDs; this patch makes an
	exception for a known-good system (based on DMI information).

Signed-off-by: Alan Stern 
Tested-by: Dâniel Fraga 
Tested-by: Andrey Rahmatullin 
Tested-by: Steven Rostedt 
Reviewed-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

USB: EHCI: fix crash during suspend on ASUS computers

2012-05-11T12:14:42+00:00

commit 151b61284776be2d6f02d48c23c3625678960b97 upstream.

This patch (as1545) fixes a problem affecting several ASUS computers:
The machine crashes or corrupts memory when going into suspend if the
ehci-hcd driver is bound to any controllers.  Users have been forced
to unbind or unload ehci-hcd before putting their systems to sleep.

After extensive testing, it was determined that the machines don't
like going into suspend when any EHCI controllers are in the PCI D3
power state.  Presumably this is a firmware bug, but there's nothing
we can do about it except to avoid putting the controllers in D3
during system sleep.

The patch adds a new flag to indicate whether the problem is present,
and avoids changing the controller's power state if the flag is set.
Runtime suspend is unaffected; this matters only for system suspend.
However as a side effect, the controller will not respond to remote
wakeup requests while the system is asleep.  Hence USB wakeup is not
functional -- but of course, this is already true in the current state
of affairs.

This fixes Bugzilla #42728.

Signed-off-by: Alan Stern 
Tested-by: Steven Rostedt 
Tested-by: Andrey Rahmatullin 
Tested-by: Oleksij Rempel (fishor) 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

USB: fix ehci alignment error

2011-10-10T23:43:53+00:00

The Kirkwood gave an unaligned memory access error on
line 742 of drivers/usb/host/echi-hcd.c:
"ehci->last_periodic_enable = ktime_get_real();"

Signed-off-by: Harro Haan 
Cc: stable 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

xHCI: set USB2 hardware LPM

2011-09-26T22:51:10+00:00

If the device pass the USB2 software LPM and the host supports hardware
LPM, enable hardware LPM for the device to let the host decide when to
put the link into lower power state.

If hardware LPM is enabled for a port and driver wants to put it into
suspend, it must first disable hardware LPM, resume the port into U0,
and then suspend the port.

Signed-off-by: Andiry Xu 
Signed-off-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman

usb: Make core allocate resources per PCI-device.

2011-03-14T01:23:06+00:00

Introduce the notion of a PCI device that may be associated with more than
one USB host controller driver (struct usb_hcd).  This patch is the start
of the work to separate the xHCI host controller into two roothubs: a USB
3.0 roothub with SuperSpeed-only ports, and a USB 2.0 roothub with
HS/FS/LS ports.

One usb_hcd structure is designated to be the "primary HCD", and a pointer
is added to the usb_hcd structure to keep track of that.  A new function
call, usb_hcd_is_primary_hcd() is added to check whether the USB hcd is
marked as the primary HCD (or if it is not part of a roothub pair).  To
allow the USB core and xHCI driver to access either roothub in a pair, a
"shared_hcd" pointer is added to the usb_hcd structure.

Add a new function, usb_create_shared_hcd(), that does roothub allocation
for paired roothubs.  It will act just like usb_create_hcd() did if the
primary_hcd pointer argument is NULL.  If it is passed a non-NULL
primary_hcd pointer, it sets usb_hcd->shared_hcd and usb_hcd->primary_hcd
fields.  It will also skip the bandwidth_mutex allocation, and set the
secondary hcd's bandwidth_mutex pointer to the primary HCD's mutex.

IRQs are only allocated once for the primary roothub.

Introduce a new usb_hcd driver flag that indicates the host controller
driver wants to create two roothubs.  If the HCD_SHARED flag is set, then
the USB core PCI probe methods will allocate a second roothub, and make
sure that second roothub gets freed during rmmod and in initialization
error paths.

When usb_hc_died() is called with the primary HCD, make sure that any
roothubs that share that host controller are also marked as being dead.

Signed-off-by: Sarah Sharp

usb: Store bus type in usb_hcd, not in driver flags.

2011-03-14T01:07:15+00:00

The xHCI driver essentially has both a USB 2.0 and a USB 3.0 roothub.  So
setting the HCD_USB3 bits in the hcd->driver->flags is a bit misleading.
Add a new field to usb_hcd, bcdUSB.  Store the result of
hcd->driver->flags & HCD_MASK in it.  Later, when we have the xHCI driver
register the two roothubs, we'll set the usb_hcd->bcdUSB field to HCD_USB2
for the USB 2.0 roothub, and HCD_USB3 for the USB 3.0 roothub.

Signed-off-by: Sarah Sharp

usb: Change usb_hcd->bandwidth_mutex to a pointer.

2011-03-14T01:07:14+00:00

Change the bandwith_mutex in struct usb_hcd to a pointer.  This will allow
the pointer to be shared across usb_hcds for the upcoming work to split
the xHCI driver roothub into a USB 2.0/1.1 and a USB 3.0 bus.

Signed-off-by: Sarah Sharp