Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 25 1月, 2013 3 次提交
  3. 12 1月, 2013 6 次提交
  5. 08 1月, 2013 1 次提交
  7. 04 1月, 2013 5 次提交
    • G
      Drivers: usb: host: ehci-orion.c: remove __devinitdata marking · 59a609a9
      由 Greg Kroah-Hartman 提交于 
      This snuck in from a different tree during the merge and needs to be
removed.

Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59a609a9
    • J
      usb: host: xhci: remove unused trb var in xhci_irq() · 026630d0
      由 Javier Martinez Canillas 提交于 
      The union xhci_trb *trb variable is defined and assigned
inside the xHCI IRQ handler function but is never used.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      026630d0
    • S
      xhci: Avoid "dead ports", add roothub port polling. · c52804a4
      由 Sarah Sharp 提交于 
      The USB core hub thread (khubd) is designed with external USB hubs in
mind.  It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.

The xHCI host controller is designed to be edge-triggered on the logical
'OR' of all the port status change bits.  When all port status change
bits are clear, and a new change bit is set, the xHC will generate a
Port Status Change Event.  If another change bit is set in the same port
status register before the first bit is cleared, it will not send
another event.

This means that the hub code may lose port status changes because of
race conditions between clearing change bits.  The user sees this as a
"dead port" that doesn't react to device connects.

The fix is to turn on port polling whenever a new change bit is set.
Once the USB core issues a hub status request that shows that no change
bits are set in any USB ports, turn off port polling.

We can't allow the USB core to poll the roothub for port events during
host suspend because if the PCI host is in D3cold, the port registers
will be all f's.  Instead, stop the port polling timer, and
unconditionally restart it when the host resumes.  If there are no port
change bits set after the resume, the first call to hub_status_data will
disable polling.

This patch should be backported to stable kernels with the first xHCI
support, 2.6.31 and newer, that include the commit
0f2a7930 "USB: xhci: Root hub support."
There will be merge conflicts because the check for HC_STATE_SUSPENDED
was moved into xhci_suspend in 3.8.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
      c52804a4
    • S
      USB: Allow USB 3.0 ports to be disabled. · 41e7e056
      由 Sarah Sharp 提交于 
      If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port.  Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects.  To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.

The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes.  We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect.  However,
external USB 3.0 hubs don't need this code.  They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set.  Therefore it doesn't make sense to
put this code in the USB core.

This patch is part of a series to fix several reports of infinite loops
on device enumeration failure.  This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller.  The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.

This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72 "usbcore: refine warm
reset logic"
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NJohn Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
      41e7e056
    • S
      xhci: Handle HS bulk/ctrl endpoints that don't NAK. · 55c1945e
      由 Sarah Sharp 提交于 
      A high speed control or bulk endpoint may have bInterval set to zero,
which means it does not NAK.  If bInterval is non-zero, it means the
endpoint NAKs at a rate of 2^(bInterval - 1).

The xHCI code to compute the NAK interval does not handle the special
case of zero properly.  The current code unconditionally subtracts one
from bInterval and uses it as an exponent.  This causes a very large
bInterval to be used, and warning messages like these will be printed:

usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes

This may cause the xHCI host hardware to reject the Configure Endpoint
command, which means the HS device will be unusable under xHCI ports.

This patch should be backported to kernels as old as 2.6.31, that contain
commit dfa49c4a "USB: xhci - fix math in
xhci_get_endpoint_interval()".
Reported-by: NVincent Pelletier <plr.vincent@gmail.com>
Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      55c1945e
  9. 13 12月, 2012 1 次提交
  11. 29 11月, 2012 1 次提交
  13. 27 11月, 2012 1 次提交
    • A
      USB: OHCI: workaround for hardware bug: retired TDs not added to the Done Queue · 50ce5c06
      由 Alan Stern 提交于 
      This patch (as1636) is a partial workaround for a hardware bug
affecting OHCI controllers by NVIDIA at least, maybe others too.  When
the controller retires a Transfer Descriptor, it is supposed to add
the TD onto the Done Queue.  But sometimes this doesn't happen, with
the result that ohci-hcd never realizes the corresponding transfer has
finished.  Symptoms can vary; a typical result is that USB audio stops
working after a while.

The patch works around the problem by recognizing that TDs are always
processed in order.  Therefore, if a later TD is found on the Done
Queue than all the earlier TDs for the same endpoint must be finished
as well.

Unfortunately this won't solve the problem in cases where the missing
TD is the last one in the endpoint's queue.  A complete fix would
require a signficant amount of change to the driver.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NOliver Neukum <oneukum@suse.de>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50ce5c06
  15. 24 11月, 2012 1 次提交
  17. 22 11月, 2012 5 次提交
  19. 15 11月, 2012 4 次提交
  21. 14 11月, 2012 1 次提交
  23. 13 11月, 2012 7 次提交
    • F
      usb: host: xhci: move HC_STATE_SUSPENDED check to xhci_suspend() · 77b84767
      由 Felipe Balbi 提交于 
      that check will have to be done by all users
of xhci_suspend() so it sounds a lot better to
move the check to xhci_suspend() in order to
avoid code duplication.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      77b84767
    • A
      usb: host: xhci: Stricter conditional for Z1 system models for Compliance Mode Patch · b0e4e606
      由 Alexis R. Cortes 提交于 
      This minor patch creates a more stricter conditional for the Z1 sytems for applying
the Compliance Mode Patch, this to avoid the quirk to be applied to models that
contain a "Z1" in their dmi product string but are different from Z1 systems.

This patch should be backported to stable kernels as old as 3.2, that
contain the commit 71c731a2 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: NAlexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      b0e4e606
    • S
      xhci: Extend Fresco Logic MSI quirk. · bba18e33
      由 Sarah Sharp 提交于 
      Ali reports that plugging a device into the Fresco Logic xHCI host with
PCI device ID 1400 produces an IRQ error:

 do_IRQ: 3.176 No irq handler for vector (irq -1)

Other early Fresco Logic host revisions don't support MSI, even though
their PCI config space claims they do.  Extend the quirk to disabling
MSI to this chipset revision.  Also enable the short transfer quirk,
since it's likely this revision also has that quirk, and it should be
harmless to enable.

04:00.0 0c03: 1b73:1400 (rev 01) (prog-if 30 [XHCI])
        Subsystem: 1d5c:1000
        Physical Slot: 3
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 51
        Region 0: Memory at d4600000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000feeff00c  Data: 41b1
        Capabilities: [80] Express (v1) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Kernel driver in use: xhci_hcd

This patch should be backported to stable kernels as old as 2.6.36, that
contain the commit f5182b41 "xhci:
Disable MSI for some Fresco Logic hosts."
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NA Sh <smr.ash1991@gmail.com>
Tested-by: NA Sh <smr.ash1991@gmail.com>
Cc: stable@vger.kernel.org
      bba18e33
    • J
      xhci: fix null-pointer dereference when destroying half-built segment rings · 68e5254a
      由 Julius Werner 提交于 
      xhci_alloc_segments_for_ring() builds a list of xhci_segments and links
the tail to head at the end (forming a ring). When it bails out for OOM
reasons half-way through, it tries to destroy its half-built list with
xhci_free_segments_for_ring(), even though it is not a ring yet. This
causes a null-pointer dereference upon hitting the last element.

Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes
the output parameters to be valid upon this kind of OOM failure, and
calls xhci_ring_free() on them. Since the (incomplete) list/ring should
already be destroyed in that case, this would lead to a use after free.

This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().

This patch should be backported to kernels as old as 2.6.31, that
contains the commit 0ebbab37 "USB: xhci:
Ring allocation and initialization."

A separate patch will need to be developed for kernels older than 3.4,
since the ring allocation code was refactored in that kernel.
Signed-off-by: NJulius Werner <jwerner@chromium.org>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      68e5254a
    • S
      xHCI: Fix TD Size calculation on 1.0 hosts. · 4525c0a1
      由 Sarah Sharp 提交于 
      The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB.  The TD Size value for the last TRB in a TD must
always be zero.

The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong.  First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10.  The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.

Third, it uses roundup instead of DIV_ROUND_UP.  The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up.  DIV_ROUND_UP is the right function to use
in that case.

With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0

With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0

This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f2 "xhci 1.0: Update TD
size field format."
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NChintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: NShimmer Huang <shimmering.h@gmail.com>
Tested-by: NBhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: NShimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
      4525c0a1
    • S
      xhci: Fix conditional check in bandwidth calculation. · 392a07ae
      由 Sarah Sharp 提交于 
      David reports that at drivers/usb/host/xhci.c:2257:

static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
    return (ep_type == ISOC_IN_EP || ep_type != INT_IN_EP);
}

The static analyser cppcheck says

[linux-3.7-rc2/drivers/usb/host/xhci.c:2257]: (style) Redundant condition: If ep_type == 5, the comparison ep_type != 7 is always true.

Maybe the original programmer intention was something like

static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
    return (ep_type == ISOC_IN_EP || ep_type == INT_IN_EP);
}

Fix this.

This patch should be backported to stable kernels as old as 3.2, that
contain the commit 2b698999 "xhci: USB
3.0 BW checking."
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NDavid Binderman <dcb314@hotmail.com>
Cc: stable@vger.kernel.org
      392a07ae
    • S
      xhci: Avoid global symbol pollution with handshake. · 2611bd18
      由 Sarah Sharp 提交于 
      Non-static xHCI driver symbols should start with the "xhci_" prefix, in
order to avoid namespace pollution.  Rename the "handshake" function to
"xhci_handshake".
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NBen Hutchings <ben@decadent.org.uk>
      2611bd18
  25. 12 11月, 2012 2 次提交
    • A
      USB: EHCI: bugfix: urb->hcpriv should not be NULL · 2656a9ab
      由 Alan Stern 提交于 
      This patch (as1632b) fixes a bug in ehci-hcd.  The USB core uses
urb->hcpriv to determine whether or not an URB is active; host
controller drivers are supposed to set this pointer to a non-NULL
value when an URB is queued.  However ehci-hcd sets it to NULL for
isochronous URBs, which defeats the check in usbcore.

In itself this isn't a big deal.  But people have recently found that
certain sequences of actions will cause the snd-usb-audio driver to
reuse URBs without waiting for them to complete.  In the absence of
proper checking by usbcore, the URBs get added to their endpoint list
twice.  This leads to list corruption and a system freeze.

The patch makes ehci-hcd assign a meaningful value to urb->hcpriv for
isochronous URBs.  Improving robustness always helps.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NArtem S. Tashkinov <t.artem@lycos.com>
Reported-by: NChristof Meerwald <cmeerw@cmeerw.org>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2656a9ab
    • A
      USB: EHCI: miscellaneous cleanups for the library conversion · 1b36810e
      由 Alan Stern 提交于 
      This patch (as1630) cleans up a few minor items resulting from the
split-up of the ehci-hcd driver:

	Remove the product_desc string from the ehci_driver_overrides
	structure.  All drivers will use the generic "EHCI Host
	Controller" string.  (This was requested by Felipe Balbi.)

	Allow drivers to pass a NULL pointer to ehci_init_driver()
	if they don't have to override any settings.

	Remove a #define symbol that is no longer used from the
	ChipIdea host driver.

	Rename overrides to pci_overrides in ehci-pci.c, for
	consistency with ehci-platform.c.

	Mark the *_overrides structures as __initdata.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1b36810e
  27. 06 11月, 2012 2 次提交