Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 09 12月, 2017 3 次提交
  3. 07 11月, 2017 1 次提交
    • G
      USB: host: xhci: Remove redundant license text · 9ed64195
      由 Greg Kroah-Hartman 提交于 
      Now that the SPDX tag is in all USB files, that identifies the license
in a specific and legally-defined manner.  So the extra GPL text wording
can be removed as it is no longer needed at all.

This is done on a quest to remove the 700+ different ways that files in
the kernel describe the GPL license text.  And there's unneeded stuff
like the address (sometimes incorrect) for the FSF which is never
needed.

No copyright headers or other non-license-description text was removed.

Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ed64195
  5. 04 11月, 2017 1 次提交
  7. 02 11月, 2017 1 次提交
  9. 17 10月, 2017 1 次提交
  11. 05 10月, 2017 2 次提交
  13. 18 9月, 2017 2 次提交
  15. 28 8月, 2017 1 次提交
    • J
      usb: xhci: Support enabling of compliance mode for xhci 1.1 · 4b562bd2
      由 Jack Pham 提交于 
      To perform SuperSpeed compliance testing the port should first
be placed into compliance mode. For xHCI 1.0 and prior this
transition happens automatically when the port is in Training
and encounters an LFPS timeout. Thus running compliance tests
against a test appliance may simply just work by simply plugging
in to the downstream port.

However starting with xHCI 1.1 the transition from Polling.LFPS
to compliance mode may be disabled by default and needs to be
explicitly enabled by writing to the PLS field of the PORTSC
register, which sets an internal 'CTE' (Compliance Transition
Enabled) flag so that the port will perform the transition the
next time it encounters LFPS timeout. Whether this is disabled or
not is determined by the 'CTC' (Compliance Transition Capability)
bit in the HCCPARAMS2 capability register.

In order to allow a test operator to change this if needed, allow
a test driver (such as drivers/usb/misc/lvstest.c) to send a
SET_FEATURE(PORT_LINK_STATE) control message to the root hub to
update the link state prior to connecting to the port. Subsequently,
placing the port in warm reset would then disable the flag.
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4b562bd2
  17. 17 8月, 2017 1 次提交
  19. 20 7月, 2017 3 次提交
  21. 20 6月, 2017 1 次提交
  23. 18 5月, 2017 1 次提交
  25. 18 4月, 2017 1 次提交
  27. 08 4月, 2017 4 次提交
  29. 25 1月, 2017 4 次提交
  31. 20 10月, 2016 2 次提交
  33. 16 8月, 2016 1 次提交
    • J
      usb: xhci: Fix panic if disconnect · 88716a93
      由 Jim Lin 提交于 
      After a device is disconnected, xhci_stop_device() will be invoked
in xhci_bus_suspend().
Also the "disconnect" IRQ will have ISR to invoke
xhci_free_virt_device() in this sequence.
xhci_irq -> xhci_handle_event -> handle_cmd_completion ->
xhci_handle_cmd_disable_slot -> xhci_free_virt_device

If xhci->devs[slot_id] has been assigned to NULL in
xhci_free_virt_device(), then virt_dev->eps[i].ring in
xhci_stop_device() may point to an invlid address to cause kernel
panic.

virt_dev = xhci->devs[slot_id];
:
if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)

[] Unable to handle kernel paging request at virtual address 00001a68
[] pgd=ffffffc001430000
[] [00001a68] *pgd=000000013c807003, *pud=000000013c807003,
*pmd=000000013c808003, *pte=0000000000000000
[] Internal error: Oops: 96000006 [#1] PREEMPT SMP
[] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G     U
[] Workqueue: pm pm_runtime_work
[] task: ffffffc0bc0e0bc0 ti: ffffffc0bc0ec000 task.ti:
ffffffc0bc0ec000
[] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4

This issue is found when running with realtek ethernet device
(0bda:8153).
Signed-off-by: NJim Lin <jilin@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88716a93
  35. 04 2月, 2016 1 次提交
  37. 12 12月, 2015 1 次提交
    • M
      xhci: fix usb2 resume timing and races. · f69115fd
      由 Mathias Nyman 提交于 
      According to USB 2 specs ports need to signal resume for at least 20ms,
in practice even longer, before moving to U0 state.
Both host and devices can initiate resume.

On device initiated resume, a port status interrupt with the port in resume
state in issued. The interrupt handler tags a resume_done[port]
timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer.
Root hub timer requests for port status, finds the port in resume state,
checks if resume_done[port] timestamp passed, and set port to U0 state.

On host initiated resume, current code sets the port to resume state,
sleep 20ms, and finally sets the port to U0 state. This should also
be changed to work in a similar way as the device initiated resume, with
timestamp tagging, but that is not yet tested and will be a separate
fix later.

There are a few issues with this approach

1. A host initiated resume will also generate a resume event. The event
   handler will find the port in resume state, believe it's a device
   initiated resume, and act accordingly.

2. A port status request might cut the resume signalling short if a
   get_port_status request is handled during the host resume signalling.
   The port will be found in resume state. The timestamp is not set leading
   to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0.
   get_port_status will proceed with moving the port to U0.

3. If an error, or anything else happens to the port during device
   initiated resume signalling it will leave all the device resume
   parameters hanging uncleared, preventing further suspend, returning
   -EBUSY, and cause the pm thread to busyloop trying to enter suspend.

Fix this by using the existing resuming_ports bitfield to indicate that
resume signalling timing is taken care of.
Check if the resume_done[port] is set before using it for timestamp
comparison, and also clear out any resume signalling related variables
if port is not in U0 or Resume state

This issue was discovered when a PM thread busylooped, trying to runtime
suspend the xhci USB 2 roothub on a Dell XPS

Cc: stable <stable@vger.kernel.org>
Reported-by: NDaniel J Blueman <daniel@quora.org>
Tested-by: NDaniel J Blueman <daniel@quora.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f69115fd
  39. 02 12月, 2015 1 次提交
  41. 19 11月, 2015 1 次提交
    • M
      xhci: Fix a race in usb2 LPM resume, blocking U3 for usb2 devices · dad67d5f
      由 Mathias Nyman 提交于 
      Clear device initiated resume variables once device is fully up and running
in U0 state.

Resume needs to be signaled for 20ms for usb2 devices before they can be
moved to U0 state.

An interrupt is triggered if a device initiates resume. As we handle the
event in interrupt context we can not sleep for 20ms, so we instead set
a resume flag, a timestamp, and start the roothub polling.

The roothub code will later move the port to U0 when it finds a port in
resume state with the resume flag set, and timestamp passed by 20ms.

A host initiated resume is however not done in interrupt context, and
host initiated resume code will directly signal resume, wait 20ms and then
move the port to U0.

These two codepaths can race, if we are in the middle of a host initated
resume, while sleeping for 20ms, we may handle a port event and find the
port in resume state. The port event handling code will assume the resume
was device initiated and set the resume flag and timestamp.

Root hub code will however not catch the port in resume state again as the
host initated resume code has already moved the port to U0.
The resume flag and timestamp will remain set for this port preventing port
from suspending again  (LPM setting port to U3)

Fix this for now by always clearing the device initated resume parameters
once port is in U0

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dad67d5f
  43. 04 10月, 2015 4 次提交
  45. 23 7月, 2015 2 次提交