Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 16 6月, 2011 3 次提交
    • S
      xhci: Don't warn about zeroed bMaxBurst descriptor field. · d2333632
      由 Sarah Sharp 提交于 
      The USB 3.0 specification says that the bMaxBurst field in the SuperSpeed
Endpoint Companion descriptor is supposed to indicate how many packets a
SS device can handle before it needs to wait for an explicit handshake
from the host controller.  A zero value means the device can only handle
one packet before it needs a handshake.  Remove a warning in the xHCI
driver that implies this is an invalid value.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      d2333632
    • S
      USB: Free bandwidth when usb_disable_device is called. · fccf4e86
      由 Sarah Sharp 提交于 
      Tanya ran into an issue when trying to switch a UAS device from the BOT
configuration to the UAS configuration via the bConfigurationValue sysfs
file.  Before installing the UAS configuration, set_bConfigurationValue()
calls usb_disable_device().  That function is supposed to remove all host
controller resources associated with that device, but it leaves some state
in the xHCI host controller.

Commit 0791971b
	usb: allow drivers to use allocated bandwidth until unbound
added a call to usb_disable_device() in usb_set_configuration(), before
the xHCI bandwidth functions were invoked.  That commit fixed a bug, but
also introduced a bug that is triggered when a configured device is
switched to a new configuration.

usb_disable_device() goes through all the motions of unbinding the drivers
attached to active interfaces and removing the USB core structures
associated with those interfaces, but it doesn't actually remove the
endpoints from the internal xHCI host controller bandwidth structures.

When usb_disable_device() calls usb_disable_endpoint() with reset_hardware
set to true, the entries in udev->ep_out and udev->ep_in will be set to
NULL.  Usually, when the USB core installs a new configuration,
usb_hcd_alloc_bandwidth() will drop all non-NULL endpoints in udev->ep_out
and udev->ep_in before adding any new endpoints.  However, when the new
UAS configuration was added, all those entries were null, so none of the
old endpoints in the BOT configuration were dropped.

The xHCI driver blindly added the UAS configuration endpoints, and some of
the endpoint addresses overlapped with the old BOT configuration
endpoints.  This caused the xHCI host to reject the Configure Endpoint
command.  Now that the xHCI driver code is cleaned up to reject a
double-add of active endpoints, we need to fix the USB core to properly
drop old endpoints in usb_disable_device().

If the host controller driver needs bandwidth checking support, make
usb_disable_device() call usb_disable_endpoint() with
reset_hardware set to false, drop the endpoints from the xHCI host
controller, and then call usb_disable_endpoint() again with
reset_hardware set to true.

The first call to usb_disable_endpoint() will cancel any pending URBs and
wait on them to be freed in usb_hcd_disable_endpoint(), but will keep the
pointers in udev->ep_out and udev->ep in intact.  Then
usb_hcd_alloc_bandwidth() will use those pointers to know which endpoints
to drop.

The final call to usb_disable_endpoint() will do two things:

1. It will call usb_hcd_disable_endpoint() again, which should be harmless
since the ep->urb_list should be empty after the first call to
usb_disable_endpoint() returns.

2. It will set the entries in udev->ep_out and udev->ep in to NULL, and call
usb_hcd_disable_endpoint().  That call will have no effect, since the xHCI
driver doesn't set the endpoint_disable function pointer.

Note that usb_disable_device() will now need to be called with
hcd->bandwidth_mutex held.

This should be backported to kernels as old as 2.6.32.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NTanya Brokhman <tlinder@codeaurora.org>
Cc: ablay@codeaurora.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@kernel.org
      fccf4e86
    • S
      xhci: Reject double add of active endpoints. · fa75ac37
      由 Sarah Sharp 提交于 
      While trying to switch a UAS device from the BOT configuration to the UAS
configuration via the bConfigurationValue file, Tanya ran into an issue in
the USB core.  usb_disable_device() sets entries in udev->ep_out and
udev->ep_out to NULL, but doesn't call into the xHCI bandwidth management
functions to remove the BOT configuration endpoints from the xHCI host's
internal structures.

The USB core would then attempt to add endpoints for the UAS
configuration, and some of the endpoints had the same address as endpoints
in the BOT configuration.  The xHCI driver blindly added the endpoints
again, but the xHCI host controller rejected the Configure Endpoint
command because active endpoints were added without being dropped.

Make the xHCI driver reject calls to xhci_add_endpoint() that attempt to
add active endpoints without first calling xhci_drop_endpoint().

This should be backported to kernels as old as 2.6.31.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NTanya Brokhman <tlinder@codeaurora.org>
Cc: stable@kernel.org
      fa75ac37
  3. 15 6月, 2011 1 次提交
  5. 09 6月, 2011 3 次提交
  7. 08 6月, 2011 5 次提交
    • G
      Revert "USB: option: add ID for ZTE MF 330" · 3095ec89
      由 Greg Kroah-Hartman 提交于 
      This reverts commit a559d2c8.

Turns out that device id 0x1d6b:0x0002 is a USB hub, which causes havoc
when the option driver tries to bind to it.

So revert this as it doesn't seem to be needed at all.

Thanks to Michael Tokarev and Paweł Drobek for working on resolving this
issue.

Cc: Paweł Drobek <pawel.drobek@gmail.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3095ec89
    • J
      drivers/usb/host/ohci-pxa27x.c: add missing clk_put · 7febe2be
      由 Julia Lawall 提交于 
      Add a label before the call to clk_put and jump to that in the error
handling code that occurs after the call to clk_get has succeeded.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@r exists@
expression e1,e2;
statement S;
@@

e1 = clk_get@p1(...);
... when != e1 = e2
    when != clk_put(e1)
    when any
if (...) { ... when != clk_put(e1)
               when != if (...) { ... clk_put(e1) ... }
* return@p3 ...;
 } else S
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Acked-by: NEric Miao <eric.y.miao@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7febe2be
    • A
      USB: CONFIG_USB_GADGET_DUALSPEED is not user-configurable · 97b2f900
      由 Alan Stern 提交于 
      This patch (as1468) changes the Kconfig definition for
USB_GADGET_DUALSPEED.  This option is determined entirely by which
device controller drivers are to be built, through Select statements;
it does not need to be (and should not be) configurable by the user.

Also, the "default n" line is superfluous -- everything defaults to N.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      97b2f900
    • A
      USB: dummy-hcd needs the has_tt flag · c5c69f3f
      由 Alan Stern 提交于 
      Like with other host controllers capable of operating at both high
speed and full speed, we need to indicate that the emulated controller
presented by dummy-hcd has this ability.  Otherwise usbcore will not
accept full-speed gadgets under dummy-hcd.  This patch (as1469) sets
the appropriate has_tt flag.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c5c69f3f
    • A
      usb-storage: redo incorrect reads · 21c13a4f
      由 Alan Stern 提交于 
      Some USB mass-storage devices have bugs that cause them not to handle
the first READ(10) command they receive correctly.  The Corsair
Padlock v2 returns completely bogus data for its first read (possibly
it returns the data in encrypted form even though the device is
supposed to be unlocked).  The Feiya SD/SDHC card reader fails to
complete the first READ(10) command after it is plugged in or after a
new card is inserted, returning a status code that indicates it thinks
the command was invalid, which prevents the kernel from retrying the
read.

Since the first read of a new device or a new medium is for the
partition sector, the kernel is unable to retrieve the device's
partition table.  Users have to manually issue an "hdparm -z" or
"blockdev --rereadpt" command before they can access the device.

This patch (as1470) works around the problem.  It adds a new quirk
flag, US_FL_INVALID_READ10, indicating that the first READ(10) should
always be retried immediately, as should any failing READ(10) commands
(provided the preceding READ(10) command succeeded, to avoid getting
stuck in a loop).  The patch also adds appropriate unusual_devs
entries containing the new flag.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NSven Geggus <sven-usbst@geggus.net>
Tested-by: NPaul Hartman <paul.hartman+linux@gmail.com>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      21c13a4f
  9. 07 6月, 2011 15 次提交
  11. 06 6月, 2011 1 次提交
    • D
      USB: xhci - fix interval calculation for FS isoc endpoints · cd3c18ba
      由 Dmitry Torokhov 提交于 
      Full-speed isoc endpoints specify interval in exponent based form in
frames, not microframes, so we need to adjust accordingly.

NEC xHCI host controllers will return an error code of 0x11 if a full
speed isochronous endpoint is added with the Interval field set to
something less than 3 (2^3 = 8 microframes, or one frame).  It is
impossible for a full speed device to have an interval smaller than one
frame.

This was always an issue in the xHCI driver, but commit
dfa49c4a "USB: xhci - fix math in
xhci_get_endpoint_interval()" removed the clamping of the minimum value
in the Interval field, which revealed this bug.

This needs to be backported to stable kernels back to 2.6.31.
Reported-by: NMatt Evans <matt@ozlabs.org>
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      cd3c18ba
  13. 04 6月, 2011 1 次提交
  15. 03 6月, 2011 4 次提交
  17. 02 6月, 2011 1 次提交
  19. 28 5月, 2011 3 次提交
    • S
      Intel xhci: Limit number of active endpoints to 64. · 2cf95c18
      由 Sarah Sharp 提交于 
      The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle.  Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't.  Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.

Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active.  This gets a little
tricky, because commands to change the number of active endpoints can
fail.  This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.

Fail a new device allocation if we don't have room for the new default
control endpoint.  Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.

Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints.  That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed.  If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.

To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints.  Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources.  When the configure
endpoint command completes, subtract off the dropped endpoints.

This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.

(Originally my plan had been to push the resource allocation down into the
ring allocation functions.  However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds.  A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      2cf95c18
    • S
      Intel xhci: Ignore spurious successful event. · ad808333
      由 Sarah Sharp 提交于 
      The xHCI host controller in the Panther Point chipset sometimes produces
spurious events on the event ring.  If it receives a short packet, it
first puts a Transfer Event with a short transfer completion code on the
event ring.  Then it puts a Transfer Event with a successful completion
code on the ring for the same TD.  The xHCI driver correctly processes the
short transfer completion code, gives the URB back to the driver, and then
prints a warning in dmesg about the spurious event.  These warning
messages really fill up dmesg when an HD webcam is plugged into xHCI.

This spurious successful event behavior isn't technically disallowed by
the xHCI specification, so make the xHCI driver just ignore the spurious
completion event.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      ad808333
    • S
      Intel xhci: Support EHCI/xHCI port switching. · 69e848c2
      由 Sarah Sharp 提交于 
      The Intel Panther Point chipsets contain an EHCI and xHCI host controller
that shares some number of skew-dependent ports.  These ports can be
switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX
that is controlled by registers in the xHCI PCI configuration space.  The
USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled
separately from the USB 2.0 data wires.

This switchover mechanism is there to support users who do a custom
install of certain non-Linux operating systems that don't have official
USB 3.0 support.  By default, the ports are under EHCI, SuperSpeed
terminations are off, and USB 3.0 devices will show up under the EHCI
controller at reduced speeds.  (This was more palatable for the marketing
folks than having completely dead USB 3.0 ports if no xHCI drivers are
available.)  Users should be able to turn on xHCI by default through a
BIOS option, but users are happiest when they don't have to change random
BIOS settings.

This patch introduces a driver method to switchover the ports from EHCI to
xHCI before the EHCI driver finishes PCI enumeration.  We want to switch
the ports over before the USB core has the chance to enumerate devices
under EHCI, or boot from USB mass storage will fail if the boot device
connects under EHCI first, and then gets disconnected when the port
switches over to xHCI.

Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI.  The
PCI quirks code will run before any other PCI probe function is called, so
this avoids the issue with boot devices.

Another issue is with BIOS behavior during system resume from hibernate.
If the BIOS doesn't support xHCI, it may switch the devices under EHCI to
allow use of the USB keyboard, mice, and mass storage devices.  It's
supposed to remember the value of the port routing registers and switch
them back when the OS attempts to take control of the xHCI host controller,
but we all know not to trust BIOS writers.

Make both the xHCI driver and the EHCI driver attempt to switchover the
ports in their PCI resume functions.  We can't guarantee which PCI device
will be resumed first, so this avoids any race conditions.  Writing a '1'
to an already set port switchover bit or a '0' to a cleared port switchover
bit should have no effect.

The xHCI PCI configuration registers will be documented in the EDS-level
chipset spec, which is not public yet.  I have permission from legal and
the Intel chipset group to release this patch early to allow good Linux
support at product launch.  I've tried to document the registers as much
as possible, so please let me know if anything is unclear.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      69e848c2
  21. 27 5月, 2011 1 次提交
  23. 26 5月, 2011 2 次提交
    • S
      xhci: STFU: Be quieter during URB submission and completion. · f444ff27
      由 Sarah Sharp 提交于 
      Unsurprisingly, URBs get submitted and completed a lot in the xHCI
driver.  If we have to print 10 lines of debug for every URB submitted
or completed, then that can cause the whole system to stay in the
interrupt handler too long, and can cause Missed Service completion
codes for isochronous transfers.

Cut down the debugging in the URB submission and completion paths:
 - Don't squawk about successful transfers, only unsuccessful ones.
 - Only print the number of bytes transferred if this was a short
   transfer.
 - Don't print the endpoint index for successful transfers (will add
   more debug to failed transfers to show endpoint index there later).
 - Stop printing MMIO writes.  This debugging shows up when the endpoint
   doorbell is rung a to start a transfer (basically for every URB).
 - Don't print out the ring enqueue and dequeue pointers
 - Stop printing when we're pointing to a link TRB.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      f444ff27
    • S
      xhci: STFU: Don't print event ring dequeue pointer. · 5153b7b3
      由 Sarah Sharp 提交于 
      Stop printing out the event ring dequeue pointer and status register in
the operational register set.  The host will report an OK status 99% of
the time the interrupt handler is called, and usually when it's really
hosed, a host controller won't even call the interrupt handler.  So the
line is really useless.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      5153b7b3