linux-stable.git/include/linux/usb.h, branch v3.10.78 Linux kernel stable tree usb: define a generic USB_RESUME_TIMEOUT macro 2015-05-06T19:56:22+00:00 Felipe Balbi balbi@ti.com 2015-02-13T20:34:25+00:00 7a2d2855fc7ba8eb962ff596f188b894f2b57eb1 commit 62f0342de1f012f3e90607d39e20fce811391169 upstream. Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 62f0342de1f012f3e90607d39e20fce811391169 upstream.

Every USB Host controller should use this new
macro to define for how long resume signalling
should be driven on the bus.

Currently, almost every single USB controller
is using a 20ms timeout for resume signalling.

That's problematic for two reasons:

a) sometimes that 20ms timer expires a little
before 20ms, which makes us fail certification

b) some (many) devices actually need more than
20ms resume signalling.

Sure, in case of (b) we can state that the device
is against the USB spec, but the fact is that
we have no control over which device the certification
lab will use. We also have no control over which host
they will use. Most likely they'll be using a Windows
PC which, again, we have no control over how that
USB stack is written and how long resume signalling
they are using.

At the end of the day, we must make sure Linux passes
electrical compliance when working as Host or as Device
and currently we don't pass compliance as host because
we're driving resume signallig for exactly 20ms and
that confuses certification test setup resulting in
Certification failure.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: remove CONFIG_USB_SUSPEND option 2013-03-28T18:10:22+00:00 Alan Stern stern@rowland.harvard.edu 2013-03-27T20:14:46+00:00 84ebc10294a3d7be4c66f51070b7aedbaa24de9b 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: Alan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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: Alan Stern <stern@rowland.harvard.edu>
CC: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: adds comment on suspend callback 2013-03-25T17:55:46+00:00 Ming Lei ming.lei@canonical.com 2013-03-15T04:08:53+00:00 303f0847925ece27129487a2bfc05199ab2a0b51 This patch adds comments on interface driver suspend callback to emphasize that the failure return value is ignored by USB core in system sleep context, so do not try to recover device for this case and let resume/reset_resume callback handle the suspend failure if needed. Also kerneldoc for usb_suspend_both() is updated with the fact. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case and let resume/reset_resume callback
handle the suspend failure if needed.

Also kerneldoc for usb_suspend_both() is updated with the
fact.

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: fix trivial usb_device kernel-doc errors 2013-03-15T18:45:16+00:00 Nishanth Menon nm@ti.com 2013-03-04T22:52:49+00:00 dad3cab3e063110b3ae3dc82a00e7aacd09b91ec Fix trivial kernel-doc warnings: Warning(include/linux/usb.h:574): No description found for parameter 'usb3_lpm_enabled' Warning(include/linux/usb.h:574): Excess struct/union/enum/typedef member 'usb_classdev' description in 'usb_device' Warning(include/linux/usb.h:574): Excess struct/union/enum/typedef member 'usbfs_dentry' description in 'usb_device' Cc: Felipe Balbi <balbi@ti.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Kosina <trivial@kernel.org> Cc: linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Fix trivial kernel-doc warnings:
Warning(include/linux/usb.h:574): No description found for parameter 'usb3_lpm_enabled'
Warning(include/linux/usb.h:574): Excess struct/union/enum/typedef member 'usb_classdev' description in 'usb_device'
Warning(include/linux/usb.h:574): Excess struct/union/enum/typedef member 'usbfs_dentry' description in 'usb_device'

Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Kosina <trivial@kernel.org>
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: add usb_hcd_{start,end}_port_resume 2013-01-25T23:06:01+00:00 Alan Stern stern@rowland.harvard.edu 2013-01-25T22:09:42+00:00 da0aa7169b97d90f4af39a9dc84d58bbe19d7e78 This patch (as1649) adds a mechanism for host controller drivers to inform usbcore when they have begun or ended resume signalling on a particular root-hub port. The core will then make sure that the root hub does not get runtime-suspended while the port resume is going on. Since commit 596d789a211d134dc5f94d1e5957248c204ef850 (USB: set hub's default autosuspend delay as 0), the system tries to suspend hubs whenever they aren't in use. While a root-hub port is being resumed, the root hub does not appear to be in use. Attempted runtime suspends fail because of the ongoing port resume, but the PM core just keeps on trying over and over again. We want to prevent this wasteful effort. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch (as1649) adds a mechanism for host controller drivers to
inform usbcore when they have begun or ended resume signalling on a
particular root-hub port.  The core will then make sure that the root
hub does not get runtime-suspended while the port resume is going on.

Since commit 596d789a211d134dc5f94d1e5957248c204ef850 (USB: set hub's
default autosuspend delay as 0), the system tries to suspend hubs
whenever they aren't in use.  While a root-hub port is being resumed,
the root hub does not appear to be in use.  Attempted runtime suspends
fail because of the ongoing port resume, but the PM core just keeps on
trying over and over again.  We want to prevent this wasteful effort.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: add USB_DEVICE_INTERFACE_CLASS macro 2012-10-31T19:58:11+00:00 Bjørn Mork bjorn@mork.no 2012-10-31T05:08:39+00:00 17b72feb2be14e6d37023267dc0e199e8e0e3fdc Matching on device and interface class with with unspecified subclass and protocol is sometimes useful. This is slightly different from USB_DEVICE_AND_INTERFACE_INFO which requires the full interface class/subclass/protocol triplet. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Matching on device and interface class with with unspecified
subclass and protocol is sometimes useful.  This is slightly
different from USB_DEVICE_AND_INTERFACE_INFO which requires
the full interface class/subclass/protocol triplet.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: speed up usb_bus_resume() 2012-10-24T21:51:22+00:00 Alan Stern stern@rowland.harvard.edu 2012-10-19T15:03:39+00:00 bfd1e910139be73fb0783a0b3171fc79e6afa031 This patch (as1620) speeds up USB root-hub resumes in the common case where every enabled port has its suspend feature set (which currently will be true for every runtime resume of the root hub). If all the enabled ports are suspended then resuming the root hub won't resume any of the downstream devices. In this case there's no need for a Resume Recovery delay, because that delay is meant to give devices a chance to get ready for active use. To keep track of the port suspend features, the patch adds a "port_is_suspended" flag to struct usb_device. This has to be tracked separately from the device's state; it's entirely possible for a USB-2 device to be suspended while the suspend feature on its parent port is clear. The reason is that devices will go into suspend whenever their parent hub does. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Peter Chen <peter.chen@freescale.com> Tested-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch (as1620) speeds up USB root-hub resumes in the common case
where every enabled port has its suspend feature set (which currently
will be true for every runtime resume of the root hub).  If all the
enabled ports are suspended then resuming the root hub won't resume
any of the downstream devices.  In this case there's no need for a
Resume Recovery delay, because that delay is meant to give devices a
chance to get ready for active use.

To keep track of the port suspend features, the patch adds a
"port_is_suspended" flag to struct usb_device.  This has to be tracked
separately from the device's state; it's entirely possible for a USB-2
device to be suspended while the suspend feature on its parent port is
clear.  The reason is that devices will go into suspend whenever their
parent hub does.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Peter Chen <peter.chen@freescale.com>
Tested-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: hub_for_each_child should skip unconnected ports 2012-10-24T21:51:21+00:00 Alan Stern stern@rowland.harvard.edu 2012-10-19T15:03:02+00:00 969ddcfc95c9a1849114fb72466d2fdea70f1d48 This patch (as1619) improves the interface to the "hub_for_each_child" macro. The name clearly suggests that the macro iterates over child devices; it does not suggest that the loop will also iterate over unnconnected ports. The patch changes the macro so that it will skip over unconnected ports and iterate only the actual child devices. The two existing call sites are updated to avoid testing for a NULL child pointer, which is now unnecessary. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch (as1619) improves the interface to the "hub_for_each_child"
macro.  The name clearly suggests that the macro iterates over child
devices; it does not suggest that the loop will also iterate over
unnconnected ports.

The patch changes the macro so that it will skip over unconnected
ports and iterate only the actual child devices.  The two existing
call sites are updated to avoid testing for a NULL child pointer,
which is now unnecessary.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: update documentation for URB_ISO_ASAP 2012-10-22T18:10:24+00:00 Alan Stern stern@rowland.harvard.edu 2012-10-01T14:31:53+00:00 a03bede5c73a6876fa891cfe82a65460dc9f4698 This patch (as1611) updates the USB documentation and kerneldoc to give a more precise meaning for the URB_ISO_ASAP flag and to explain more of the details of scheduling for isochronous URBs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch (as1611) updates the USB documentation and kerneldoc to
give a more precise meaning for the URB_ISO_ASAP flag and to explain
more of the details of scheduling for isochronous URBs.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: usb.h: remove dbg() macro 2012-10-17T18:16:13+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2012-10-05T22:09:38+00:00 2c78040c3e2735b8286bbb848db0372b8d408e2d There are no users of this macro anymore in the kernel tree, so finally delete it. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
There are no users of this macro anymore in the kernel tree, so finally
delete it.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>