Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 31 10月, 2016 1 次提交
    • F
      usb: add helper to extract bits 12:11 of wMaxPacketSize · 541b6fe6
      由 Felipe Balbi 提交于 
      According to USB Specification 2.0 table 9-4,
wMaxPacketSize is a bitfield. Endpoint's maxpacket
is laid out in bits 10:0. For high-speed,
high-bandwidth isochronous endpoints, bits 12:11
contain a multiplier to tell us how many
transactions we want to try per uframe.

This means that if we want an isochronous endpoint
to issue 3 transfers of 1024 bytes per uframe,
wMaxPacketSize should contain the value:

	1024 | (2 << 11)

or 5120 (0x1400). In order to make Host and
Peripheral controller drivers' life easier, we're
adding a helper which returns bits 12:11. Note that
no care is made WRT to checking endpoint type and
gadget's speed. That's left for drivers to handle.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      541b6fe6
  3. 19 4月, 2016 3 次提交
  5. 29 3月, 2016 1 次提交
  7. 04 3月, 2016 2 次提交
  9. 15 2月, 2016 2 次提交
  11. 25 1月, 2016 1 次提交
  13. 04 10月, 2015 1 次提交
  15. 29 7月, 2015 2 次提交
  17. 09 4月, 2013 1 次提交
  19. 25 1月, 2013 1 次提交
    • L
      usb: Using correct way to clear usb3.0 device's remote wakeup feature. · 54a3ac0c
      由 Lan Tianyu 提交于 
      Usb3.0 device defines function remote wakeup which is only for interface
recipient rather than device recipient. This is different with usb2.0 device's
remote wakeup feature which is defined for device recipient. According usb3.0
spec 9.4.5, the function remote wakeup can be modified by the SetFeature()
requests using the FUNCTION_SUSPEND feature selector. This patch is to use
correct way to disable usb3.0 device's function remote wakeup after suspend
error and resuming.

This should be backported to kernels as old as 3.4, that contain the
commit 623bef9e "USB/xhci: Enable remote
wakeup for USB3 devices."
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      54a3ac0c
  21. 09 10月, 2012 1 次提交
  23. 19 5月, 2012 2 次提交
    • S
      USB: Add macros for interrupt endpoint types. · 6538eafc
      由 Sarah Sharp 提交于 
      The USB 3.0 spec defines a new way of differentiating interrupt
endpoints.  The idea is that some interrupt endpoints are used for
notifications, i.e. they continually NAK the transfer until something
changes on the device.  Other interrupt endpoints are used as a way to
periodically transfer data.

The USB 3.0 endpoint descriptor uses bits 5:4 of bmAttributes for
interrupt endpoints, to define the endpoint as either a Notification
endpoint, or a Periodic endpoint.  Introduce macros to dig out that
information.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      6538eafc
    • S
      USB: Add support to enable/disable USB3 link states. · 1ea7e0e8
      由 Sarah Sharp 提交于 
      There are various functions within the USB core that will need to
disable USB 3.0 link power states.  For example, when a USB device
driver is being bound to an interface, we need to disable USB 3.0 LPM
until we know if the driver will allow hub-initiated LPM transitions.
Another example is when the USB core is switching alternate interface
settings.  The USB 3.0 timeout values are dependent on what endpoints
are enabled, so we want to ensure that LPM is disabled until the new alt
setting is fully installed.

Multiple functions need to disable LPM, and those functions can even be
nested.  For example, usb_bind_interface() could disable LPM, and then
call into the driver probe function, which may attempt to switch to a
different alt setting.  Therefore, we need to keep a count of the number
of functions that require LPM to be disabled at any point in time.

Introduce two new USB core API calls, usb_disable_lpm() and
usb_enable_lpm().  These functions increment and decrement a new
variable in the usb_device, lpm_disable_count.  If usb_disable_lpm()
fails, it will call usb_enable_lpm() in order to balance the
lpm_disable_count.

These two new functions must be called with the bandwidth_mutex locked.
If the bandwidth_mutex is not already held by the caller, it should
instead call usb_unlocked_disable_lpm() and usb_enable_lpm(), which take
the bandwidth_mutex before calling usb_disable_lpm() and
usb_enable_lpm(), respectively.

Introduce a new variable (timeout) in the usb3_lpm_params structure to
keep track of the currently enabled U1/U2 timeout values.  When
usb_disable_lpm() is called, and the USB device has the U1 or U2
timeouts set to a non-zero value (meaning either device-initiated or
hub-initiated LPM is enabled), attempt to disable LPM, regardless of the
state of the lpm_disable_count.  We want to ensure that all callers can
be guaranteed that LPM is disabled if usb_disable_lpm() returns zero.

Otherwise the following scenario could occur:

1. Driver A is being bound to interface 1.  usb_probe_interface()
disables LPM.  Driver A doesn't care if hub-initiated LPM is enabled, so
even though usb_disable_lpm() fails, the probe of the driver continues,
and the bandwidth mutex is dropped.

2. Meanwhile, Driver B is being bound to interface 2.
usb_probe_interface() grabs the bandwidth mutex and calls
usb_disable_lpm().  That call should attempt to disable LPM, even
though the lpm_disable_count is set to 1 by Driver A.

For usb_enable_lpm(), we attempt to enable LPM only when the
lpm_disable_count is zero.  If some step in enabling LPM fails, it will
only have a minimal impact on power consumption, and all USB device
drivers should still work properly.  Therefore don't bother to return
any error codes.

Don't enable device-initiated LPM if the device is unconfigured.  The
USB device will only accept the U1/U2_ENABLE control transfers in the
configured state.  Do enable hub-initiated LPM in that case, since
devices are allowed to accept the LGO_Ux link commands in any state.

Don't enable or disable LPM if the device is marked as not being LPM
capable.  This can happen if:
 - the USB device doesn't have a SS BOS descriptor,
 - the device's parent hub has a zeroed bHeaderDecodeLatency value, or
 - the xHCI host doesn't support LPM.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      1ea7e0e8
  25. 30 4月, 2012 1 次提交
  27. 13 3月, 2012 1 次提交
  29. 03 2月, 2012 1 次提交
  31. 02 2月, 2012 1 次提交
  33. 05 1月, 2012 1 次提交
    • F
      usb: ch9: fix up MaxStreams helper · 18b7ede5
      由 Felipe Balbi 提交于 
      According to USB 3.0 Specification Table 9-22, if
bmAttributes [4:0] are set to zero, it means "no
streams supported", but the way this helper was
defined on Linux, we will *always* have one stream
which might cause several problems.

For example on DWC3, we would tell the controller
endpoint has streams enabled and yet start transfers
with Stream ID set to 0, which would goof up the host
side.

While doing that, convert the macro to an inline
function due to the different checks we now need.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      18b7ede5
  35. 18 9月, 2011 1 次提交
    • M
      usb: Provide usb_speed_string() function · e538dfda
      由 Michal Nazarewicz 提交于 
      In a few places in the kernel, the code prints
a human-readable USB device speed (eg. "high speed").
This involves a switch statement sometimes wrapped
around in ({ ... }) block leading to code repetition.

To mitigate this issue, this commit introduces
usb_speed_string() function, which returns
a human-readable name of provided speed.

It also changes a few places switch was used to use
this new function.  This changes a bit the way the
speed is printed in few instances at the same time
standardising it.
Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e538dfda
  37. 14 9月, 2011 1 次提交
  39. 23 8月, 2011 2 次提交
  41. 03 5月, 2011 1 次提交
  43. 14 3月, 2011 1 次提交
  45. 26 2月, 2011 1 次提交
  47. 01 12月, 2010 1 次提交
  49. 23 10月, 2010 2 次提交
  51. 21 5月, 2010 3 次提交
  53. 03 3月, 2010 1 次提交
  55. 23 9月, 2009 2 次提交
  57. 16 6月, 2009 1 次提交