Skip to content

cloud-kernel
cloud-kernel

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

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 29 6月, 2020 1 次提交
  3. 25 6月, 2018 1 次提交
    • A
      USB: Report wakeup events on root-hub ports · 379cacc5
      由 Alan Stern 提交于 
      When a USB device attached to a root-hub port sends a wakeup request
to a sleeping system, we do not report the wakeup event to the PM
core.  This is because a system resume involves waking up all
suspended USB ports as quickly as possible; without the normal
USB_RESUME_TIMEOUT delay, the host controller driver doesn't set the
USB_PORT_STAT_C_SUSPEND flag and so usb_port_resume() doesn't realize
that a wakeup request was received.

However, some environments (such as Chrome OS) want to have all wakeup
events reported so they can be ascribed to the appropriate device.  To
accommodate these environments, this patch adds a new routine to the
hub driver and a corresponding new HCD method to be used when a root
hub resumes.  The HCD method returns a bitmap of ports that have
initiated a wakeup signal but not yet completed resuming.  The hub
driver can then report to the PM core that the child devices attached
to these ports initiated a wakeup event.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Suggested-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      379cacc5
  5. 22 4月, 2018 2 次提交
  7. 10 3月, 2018 3 次提交
  9. 04 11月, 2017 1 次提交
  11. 13 6月, 2017 1 次提交
  13. 18 5月, 2017 1 次提交
  15. 23 3月, 2017 1 次提交
  17. 17 3月, 2017 1 次提交
  19. 05 12月, 2016 1 次提交
    • T
      usb: hcd.h: construct hub class request constants from simpler constants · b9c2a2a3
      由 Tal Shorer 提交于 
      Currently, each hub class request constant is defined by a line like:
#define ClearHubFeature		(0x2000 | USB_REQ_CLEAR_FEATURE)

The "magic" number for the high byte is one of 0x20, 0xa0, 0x23, 0xa3.
The 0x80 bit that changes inditace USB_DIR_IN, and the 0x03 that
pops up is the difference between USB_RECIP_DEVICE (0x00) and
USB_RECIP_OTHER (0x03). The constant 0x20 bit is USB_TYPE_CLASS.

This patch eliminates those magic numbers by defining a macro to help
construct these hub class request from simpler constants.
Note that USB_RT_HUB is defined as (USB_TYPE_CLASS | USB_RECIP_DEVICE)
and that USB_RT_PORT is defined as (USB_TYPE_CLASS | USB_RECIP_OTHER).
Signed-off-by: NTal Shorer <tal.shorer@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9c2a2a3
  21. 29 4月, 2016 1 次提交
    • C
      usb: core: hub: hub_port_init lock controller instead of bus · feb26ac3
      由 Chris Bainbridge 提交于 
      The XHCI controller presents two USB buses to the system - one for USB2
and one for USB3. The hub init code (hub_port_init) is reentrant but
only locks one bus per thread, leading to a race condition failure when
two threads attempt to simultaneously initialise a USB2 and USB3 device:

[    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[   13.183701] usb 3-3: device descriptor read/all, error -110

On a test system this failure occurred on 6% of all boots.

The call traces at the point of failure are:

Call Trace:
 [<ffffffff81b9bab7>] schedule+0x37/0x90
 [<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0
 [<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30
 [<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150
 [<ffffffff817db10c>] usb_control_msg+0xbc/0xf0
 [<ffffffff817d07de>] hub_port_init+0x51e/0xb70
 [<ffffffff817d4697>] hub_event+0x817/0x1570
 [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
 [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
 [<ffffffff810f4684>] worker_thread+0x64/0x4b0
 [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
 [<ffffffff810fa7f5>] kthread+0x105/0x120
 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
 [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200

Call Trace:
 [<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40
 [<ffffffff817fd87e>] xhci_address_device+0xe/0x10
 [<ffffffff817d047f>] hub_port_init+0x1bf/0xb70
 [<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff817d4697>] hub_event+0x817/0x1570
 [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
 [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
 [<ffffffff810f4684>] worker_thread+0x64/0x4b0
 [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
 [<ffffffff810fa7f5>] kthread+0x105/0x120
 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
 [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200

Which results from the two call chains:

hub_port_init
 usb_get_device_descriptor
  usb_get_descriptor
   usb_control_msg
    usb_internal_control_msg
     usb_start_wait_urb
      usb_submit_urb / wait_for_completion_timeout / usb_kill_urb

hub_port_init
 hub_set_address
  xhci_address_device
   xhci_setup_device

Mathias Nyman explains the current behaviour violates the XHCI spec:

 hub_port_reset() will end up moving the corresponding xhci device slot
 to default state.

 As hub_port_reset() is called several times in hub_port_init() it
 sounds reasonable that we could end up with two threads having their
 xhci device slots in default state at the same time, which according to
 xhci 4.5.3 specs still is a big no no:

 "Note: Software shall not transition more than one Device Slot to the
  Default State at a time"

 So both threads fail at their next task after this.
 One fails to read the descriptor, and the other fails addressing the
 device.

Fix this in hub_port_init by locking the USB controller (instead of an
individual bus) to prevent simultaneous initialisation of both buses.

Fixes: 638139eb ("usb: hub: allow to process more usb hub events in parallel")
Link: https://lkml.org/lkml/2016/2/8/312
Link: https://lkml.org/lkml/2016/2/4/748Signed-off-by: NChris Bainbridge <chris.bainbridge@gmail.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      feb26ac3
  23. 07 2月, 2016 1 次提交
  25. 04 2月, 2016 1 次提交
  27. 02 12月, 2015 1 次提交
  29. 04 10月, 2015 1 次提交
  31. 23 9月, 2015 2 次提交
  33. 19 8月, 2015 2 次提交
  35. 15 8月, 2015 2 次提交
  37. 09 8月, 2015 1 次提交
  39. 31 5月, 2015 1 次提交
  41. 01 2月, 2015 1 次提交
  43. 10 1月, 2015 1 次提交
    • S
      usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN · 5efd2ea8
      由 Sebastian Andrzej Siewior 提交于 
      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.

Cc: stable@vger.kernel.org
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5efd2ea8
  45. 04 12月, 2014 1 次提交
  47. 04 11月, 2014 1 次提交
  49. 29 9月, 2014 2 次提交
  51. 24 9月, 2014 1 次提交
  53. 05 3月, 2014 1 次提交
  55. 11 12月, 2013 1 次提交
    • D
      usb: xhci: change enumeration scheme to 'new scheme' by default · 48fc7dbd
      由 Dan Williams 提交于 
      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: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NDavid Moore <david.moore@gmail.com>
Suggested-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      48fc7dbd
  57. 09 12月, 2013 1 次提交
  59. 12 10月, 2013 2 次提交
  61. 26 9月, 2013 1 次提交
    • H
      usb: core: implement AMD remote wakeup quirk · 7868943d
      由 Huang Rui 提交于 
      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: NHuang Rui <ray.huang@amd.com>
Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7868943d
  63. 18 9月, 2013 1 次提交
    • A
      USB: see if URB comes from a completion handler · c7ccde6e
      由 Alan Stern 提交于 
      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: NAlan Stern <stern@rowland.harvard.edu>
CC: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c7ccde6e