linux-stable.git/drivers/usb/core/message.c, branch v3.12 Linux kernel stable tree usb: fix some scripts/kernel-doc warnings 2013-08-03T03:30:14+00:00 Yacine Belkadi yacine.belkadi.1@gmail.com 2013-08-02T18:10:04+00:00 626f090c5cbbe557379978c7a9525011ad7fbbf6 When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
When building the htmldocs (in verbose mode), scripts/kernel-doc reports the
following type of warnings:

Warning(drivers/usb/core/usb.c:76): No description found for return value of
'usb_find_alt_setting'

Fix them by:
- adding some missing descriptions of return values
- using "Return" sections for those descriptions

Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: simplify the interface of usb_get_status() 2013-08-01T00:29:02+00:00 Alan Stern stern@rowland.harvard.edu 2013-07-30T19:35:40+00:00 15b7336e02d998720c5ace47036f7e539365bb05 This patch simplifies the interface presented by usb_get_status(). Instead of forcing callers to check for the proper data length and convert the status value to host byte order, the function will now do these things itself. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch simplifies the interface presented by usb_get_status().
Instead of forcing callers to check for the proper data length and
convert the status value to host byte order, the function will now
do these things itself.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: message: Fixed parenthesis error in sizeof function. 2013-05-17T17:09:26+00:00 Tülin İzer tulinizer@gmail.com 2013-05-17T07:33:05+00:00 a1fefaab1bbf9cd409cb11887953567d0a8faeb6 This patch fixes parenthesis error in sizeof function in Usb/message.c Signed-off-by: Tülin İzer <tulinizer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch fixes parenthesis error in sizeof function in Usb/message.c

Signed-off-by: Tülin İzer <tulinizer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: message: Fixed error: 'no space before bracket' 2013-05-17T17:09:25+00:00 Tülin İzer tulinizer@gmail.com 2013-05-17T07:32:35+00:00 085528e5e4e5319f6dc986b0de8c06279d6830c0 This patch fixes error: 'no space before bracket' in Usb/message.c Signed-off-by: Tülin İzer <tulinizer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch fixes error: 'no space before bracket' in Usb/message.c

Signed-off-by: Tülin İzer <tulinizer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb/core: consider link speed while looking at bMaxPower 2013-01-12T00:16:01+00:00 Sebastian Andrzej Siewior bigeasy@linutronix.de 2012-12-18T14:25:46+00:00 8d8479db3dde3ef7a9bc803e565842764fa21a53 The USB 2.0 specification says that bMaxPower is the maximum power consumption expressed in 2 mA units and the USB 3.0 specification says that it is expressed in 8 mA units. This patch adds a helper function usb_get_max_power() which computes the value based on config & usb_device's speed value. The the device descriptor dump computes the value on its own. Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The USB 2.0 specification says that bMaxPower is the maximum power
consumption expressed in 2 mA units and the USB 3.0 specification says
that it is expressed in 8 mA units.
This patch adds a helper function usb_get_max_power() which computes the
value based on config & usb_device's speed value. The the device descriptor
dump computes the value on its own.

Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: core: Free the allocated memory before exiting on error 2012-11-21T21:32:26+00:00 Sachin Kamat sachin.kamat@linaro.org 2012-11-21T05:31:19+00:00 c058f7ab94143dfa2286e496019b7ad0b95502ac 'new_interfaces' should be freed to avoid memory leak. Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
'new_interfaces' should be freed to avoid memory leak.

Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb-core: remove CONFIG_HOTPLUG ifdefs 2012-11-21T21:27:16+00:00 Bill Pemberton wfp5p@virginia.edu 2012-11-19T18:19:16+00:00 2bd6a021e887c675116ff8cdacc3af49999a2224 Remove conditional code based on CONFIG_HOTPLUG being false. It's always on now in preparation of it going away as an option. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Remove conditional code based on CONFIG_HOTPLUG being false.  It's
always on now in preparation of it going away as an option.

Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: fix endpoint-disabling for failed config changes 2012-11-12T02:06:48+00:00 Alan Stern stern@rowland.harvard.edu 2012-11-07T15:31:30+00:00 36caff5d795429c572443894e8789c2150dd796b This patch (as1631) fixes a bug that shows up when a config change fails for a device under an xHCI controller. The controller needs to be told to disable the endpoints that have been enabled for the new config. The existing code does this, but before storing the information about which endpoints were enabled! As a result, any second attempt to install the new config is doomed to fail because xhci-hcd will refuse to enable an endpoint that is already enabled. The patch optimistically initializes the new endpoints' device structures before asking the device to switch to the new config. If the request fails then the endpoint information is already stored, so we can use usb_hcd_alloc_bandwidth() to disable the endpoints with no trouble. The rest of the error path is slightly more complex now; we have to disable the new interfaces and call put_device() rather than simply deallocating them. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Matthias Schniedermeyer <ms@citd.de> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch (as1631) fixes a bug that shows up when a config change
fails for a device under an xHCI controller.  The controller needs to
be told to disable the endpoints that have been enabled for the new
config.  The existing code does this, but before storing the
information about which endpoints were enabled!  As a result, any
second attempt to install the new config is doomed to fail because
xhci-hcd will refuse to enable an endpoint that is already enabled.

The patch optimistically initializes the new endpoints' device
structures before asking the device to switch to the new config.  If
the request fails then the endpoint information is already stored, so
we can use usb_hcd_alloc_bandwidth() to disable the endpoints with no
trouble.  The rest of the error path is slightly more complex now; we
have to disable the new interfaces and call put_device() rather than
simply deallocating them.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Matthias Schniedermeyer <ms@citd.de>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: core: remove unused dbg() call in message.c 2012-09-13T18:23:03+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2012-09-13T18:23:03+00:00 c2d57aec81f3d479642523fd4d3537006168c240 It's not needed, and commented out, so just remove it. Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
It's not needed, and commented out, so just remove it.

Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: Enable Latency Tolerance Messaging (LTM). 2012-07-11T11:06:48+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2012-06-25T19:08:08+00:00 f74631e3426474183389e55f703797bd965cd356 USB 3.0 devices may optionally support a new feature called Latency Tolerance Messaging. If both the xHCI host controller and the device support LTM, it should be turned on in order to give the system hardware a better clue about the latency tolerance values of its PCI devices. Once a Set Feature request to enable LTM is received, the USB 3.0 device will begin to send LTM updates as its buffers fill or empty, and it can tolerate more or less latency. The USB 3.0 spec, section C.4.2 says that LTM should be disabled just before the device is placed into suspend. Then the device will send an updated LTM notification, so that the system doesn't think it should remain in an active state in order to satisfy the latency requirements of the suspended device. The Set and Clear Feature LTM enable command can only be sent to a configured device. The device will respond with an error if that command is sent while it is in the Default or Addressed state. Make sure to check udev->actconfig in usb_enable_ltm() and usb_disable_ltm(), and don't send those commands when the device is unconfigured. LTM should be enabled once a new configuration is installed in usb_set_configuration(). If we end up sending duplicate Set Feature LTM Enable commands on a switch from one installed configuration to another configuration, that should be harmless. Make sure that LTM is disabled before the device is unconfigured in usb_disable_device(). If no drivers are bound to the device, it doesn't make sense to allow the device to control the latency tolerance of the xHCI host controller. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> 
USB 3.0 devices may optionally support a new feature called Latency
Tolerance Messaging.  If both the xHCI host controller and the device
support LTM, it should be turned on in order to give the system hardware
a better clue about the latency tolerance values of its PCI devices.

Once a Set Feature request to enable LTM is received, the USB 3.0 device
will begin to send LTM updates as its buffers fill or empty, and it can
tolerate more or less latency.

The USB 3.0 spec, section C.4.2 says that LTM should be disabled just
before the device is placed into suspend.  Then the device will send an
updated LTM notification, so that the system doesn't think it should
remain in an active state in order to satisfy the latency requirements
of the suspended device.

The Set and Clear Feature LTM enable command can only be sent to a
configured device.  The device will respond with an error if that
command is sent while it is in the Default or Addressed state.  Make
sure to check udev->actconfig in usb_enable_ltm() and usb_disable_ltm(),
and don't send those commands when the device is unconfigured.

LTM should be enabled once a new configuration is installed in
usb_set_configuration().  If we end up sending duplicate Set Feature LTM
Enable commands on a switch from one installed configuration to another
configuration, that should be harmless.

Make sure that LTM is disabled before the device is unconfigured in
usb_disable_device().  If no drivers are bound to the device, it doesn't
make sense to allow the device to control the latency tolerance of the
xHCI host controller.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>