Skip to content

L
linux
Switch branch/tag
  1. 27 Jun, 2011 1 commit
  3. 17 Jun, 2011 4 commits
    • Sarah Sharp's avatar
      USB: Fix up URB error codes to reflect implementation. · a9e75863
      Sarah Sharp authored 
      Documentation/usb/error-codes.txt mentions that urb->status can be set to
-EXDEV, if the isochronous transfer was not fully completed.  However, in
practice, EHCI, UHCI, and OHCI all only set -EXDEV in the individual frame
status, never in the URB status.  Those host controller actually always
pass in a zero status to usb_hcd_giveback_urb, and rely on the core to set
the appropriate status value.

The xHCI driver ran into issues with the uvcvideo driver when it tried to
set -EXDEV in urb->status, because the driver refused to submit URBs, and
the userspace camera application's video froze.

Clean up the documentation to reflect the actual implementation.
Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      a9e75863
    • Sarah Sharp's avatar
      xhci: Always set urb->status to zero for isoc endpoints. · b3df3f9c
      Sarah Sharp authored 
      When the xHCI driver encounters a Missed Service Interval event for an
isochronous endpoint ring, it means the host controller skipped over
one or more isochronous TDs.  For TD that is skipped, skip_isoc_td() is
called.  This sets the frame descriptor status to -EXDEV, and also sets
the value stored in the int pointed to by status to -EXDEV.

If the isochronous TD happens to be the last TD in an URB,
handle_tx_event() will use the status variable to give back the URB to
the USB core.  That means drivers will see urb->status as -EXDEV.

It turns out that EHCI, UHCI, and OHCI always set urb->status to zero for
an isochronous urb, regardless of what the frame status is.  See
itd_complete() in ehci-sched.c:

                } else {
                        /* URB was too late */
                        desc->status = -EXDEV;
                }
        }

        /* handle completion now? */
        if (likely ((urb_index + 1) != urb->number_of_packets))
                goto done;

        /* ASSERT: it's really the last itd for this urb
        list_for_each_entry (itd, &stream->td_list, itd_list)
                BUG_ON (itd->urb == urb);
         */

        /* give urb back to the driver; completion often (re)submits */
        dev = urb->dev;
        ehci_urb_done(ehci, urb, 0);

ehci_urb_done() completes the URB with the status of the third argument, which
is always zero in this case.

It turns out that many USB webcam drivers, such as uvcvideo, cannot
handle urb->status set to a non-zero value.  They will not resubmit
their isochronous URBs in that case, and userspace will see a frozen
video.

Change the xHCI driver to be consistent with the EHCI and UHCI driver,
and always set urb->status to 0 for isochronous URBs.

This patch should be backported to kernels as old as 2.6.36
Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: "Xu, Andiry" <Andiry.Xu@amd.com>
Cc: stable@kernel.org
      b3df3f9c
    • Maarten Lankhorst's avatar
      xhci: Add reset on resume quirk for asrock p67 host · c877b3b2
      Maarten Lankhorst authored 
      The asrock p67 xhci controller completely dies on resume, add a
quirk for this, to bring the host back online after a suspend.

This should be backported to stable kernels as old as 2.6.37.
Signed-off-by: default avatarMaarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      c877b3b2
    • Alex He's avatar
      xHCI 1.0: Incompatible Device Error · f6ba6fe2
      Alex He authored 
      It is one new TRB Completion Code for the xHCI spec v1.0.
Asserted if the xHC detects a problem with a device that does not allow it to
be successfully accessed, e.g. due to a device compliance or compatibility
problem. This error may be returned by any command or transfer, and is fatal
as far as the Slot is concerned. Return -EPROTO by urb->status or frame->status
of ISOC for transfer case. And return -ENODEV for configure endpoint command,
evaluate context command and address device command if there is an incompatible
Device Error. The error codes will be sent back to the USB core to decide how
to do. It's unnecessary for other commands because after the three commands run
successfully means that the device has been accepted.
Signed-off-by: default avatarAlex He <alex.he@amd.com>
Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      f6ba6fe2
  5. 16 Jun, 2011 3 commits
    • Alan Stern's avatar
      USB: don't let errors prevent system sleep · 0af212ba
      Alan Stern authored 
      This patch (as1464) implements the recommended policy that most errors
during suspend or hibernation should not prevent the system from going
to sleep.  In particular, failure to suspend a USB driver or a USB
device should not prevent the sleep from succeeding:

Failure to suspend a device won't matter, because the device will
automatically go into suspend mode when the USB bus stops carrying
packets.  (This might be less true for USB-3.0 devices, but let's not
worry about them now.)

Failure of a driver to suspend might lead to trouble later on when the
system wakes up, but it isn't sufficient reason to prevent the system
from going to sleep.
Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0af212ba
    • Alan Stern's avatar
      USB: don't let the hub driver prevent system sleep · cbb33004
      Alan Stern authored 
      This patch (as1465) continues implementation of the policy that errors
during suspend or hibernation should not prevent the system from going
to sleep.

In this case, failure to turn on the Suspend feature for a hub port
shouldn't be reported as an error.  There are situations where this
does actually occur (such as when the device plugged into that port
was disconnected in the recent past), and it turns out to be harmless.
There's no reason for it to prevent a system sleep.

Also, don't allow the hub driver to fail a system suspend if the
downstream ports aren't all suspended.  This is also harmless (and
should never happen, given the change mentioned above); printing a
warning message in the kernel log is all we really need to do.
Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      cbb33004
    • Alan Stern's avatar
      USB: change maintainership of ohci-hcd and ehci-hcd · 578333ab
      Alan Stern authored 
      Following the loss of David Brownell, I volunteer to maintain the
ohci-hcd and ehci-hcd drivers.  This patch (as1472) makes it official.
Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      578333ab
  7. 15 Jun, 2011 4 commits
    • Alex He's avatar
      xHCI 1.0: Force Stopped Event(FSE) · e1cf486d
      Alex He authored 
      FSE shall occur on the TD natural boundary. The software ep_ring dequeue pointer
exceed the hardware ep_ring dequeue pointer in these cases of Table-3. As a
result, the event_trb(pointed by hardware dequeue pointer) of the FSE can't be
found in the current TD(pointed by software dequeue pointer). What should we do
is to figured out the FSE case and skip over it.
Signed-off-by: default avatarAlex He <alex.he@amd.com>
Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      e1cf486d
    • Sarah Sharp's avatar
      xhci: Don't warn about zeroed bMaxBurst descriptor field. · d2333632
      Sarah Sharp authored 
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      d2333632
    • Sarah Sharp's avatar
      USB: Free bandwidth when usb_disable_device is called. · fccf4e86
      Sarah Sharp authored 
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: default avatarTanya Brokhman <tlinder@codeaurora.org>
Cc: ablay@codeaurora.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@kernel.org
      fccf4e86
    • Sarah Sharp's avatar
      xhci: Reject double add of active endpoints. · fa75ac37
      Sarah Sharp authored 
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: default avatarTanya Brokhman <tlinder@codeaurora.org>
Cc: stable@kernel.org
      fa75ac37
  9. 14 Jun, 2011 2 commits
  11. 13 Jun, 2011 10 commits
  13. 12 Jun, 2011 8 commits
  15. 11 Jun, 2011 8 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7