public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Kernel development list <linux-kernel@vger.kernel.org>,
	USB list <linux-usb@vger.kernel.org>,
	Sarah Sharp <sarah.a.sharp@linux.intel.com>
Subject: Re: 3.0rc3-rc5: usb stops working after resume from suspend to ram
Date: Mon, 4 Jul 2011 10:54:36 +0200	[thread overview]
Message-ID: <201107041054.36890.a.miskiewicz@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1106301158310.1957-100000@iolanthe.rowland.org>

On Thursday 30 of June 2011, Alan Stern wrote:

> And now you know why, more or less -- we still have to figure out the
> reason for the hang.  Probably something goes wrong when cdc-ether is
> unbound from the wireless device.

Reverting patch below fixes hang.

commit fccf4e86200b8f5edd9a65da26f150e32ba79808
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Sun Jun 5 23:22:22 2011 -0700

    USB: Free bandwidth when usb_disable_device is called.
    
    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 0791971ba8fbc44e4f476079f856335ed45e6324
        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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Tanya Brokhman <tlinder@codeaurora.org>
    Cc: ablay@codeaurora.org
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable@kernel.org


> Alan Stern

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

  parent reply	other threads:[~2011-07-04  8:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-29 19:21 3.0rc3-rc5: usb stops working after resume from suspend to ram Arkadiusz Miskiewicz
2011-06-29 19:59 ` Alan Stern
2011-06-29 20:59   ` Arkadiusz Miskiewicz
2011-06-29 21:26     ` Alan Stern
2011-06-30 15:19       ` Alan Stern
2011-06-30 15:25       ` Arkadiusz Miskiewicz
2011-06-30 16:19         ` Alan Stern
2011-06-30 18:25           ` 3.0rc3-rc5: usb stops working after resume from suspend Arkadiusz Miskiewicz
2011-06-30 19:06             ` Alan Stern
2011-07-04  8:54           ` Arkadiusz Miskiewicz [this message]
2011-07-04 15:56             ` 3.0rc3-rc5: usb stops working after resume from suspend to ram Alan Stern
2011-07-05  7:10               ` Arkadiusz Miskiewicz
2011-07-05 13:57                 ` Alan Stern
2011-07-03 13:29 ` Maciej Rutecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201107041054.36890.a.miskiewicz@gmail.com \
    --to=a.miskiewicz@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sarah.a.sharp@linux.intel.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox