On 01.11.2012 12:03, Alan Stern wrote:
> On Thu, 1 Nov 2012, Sarah Sharp wrote:
>
> > On Wed, Oct 31, 2012 at 03:54:49PM -0400, Alan Stern wrote:
> > > + ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
> > > + USB_REQ_SET_CONFIGURATION, 0, configuration, 0,
> > > + NULL, 0, USB_CTRL_SET_TIMEOUT);
> > > + if (ret < 0 && cp) {
> > > + /*
> > > + * All the old state is gone, so what else can we do?
> > > + * The device is probably useless now anyway.
> > > + */
> > > + for (i = 0; i < nintf; ++i) {
> > > + usb_disable_interface(dev, cp->interface[i], true);
> >
> > usb_disable_interface() will set the udev->ep_out and udev->ep_in array
> > entries to NULL. The bandwidth functions need those arrays to figure
> > out which entries to disable.
>
> You're right. I should have realized that. :-(
>
> > Is there a particular reason why you wanted to call
> > usb_disable_interface() before calling usb_hcd_alloc_bandwidth()?
>
> Sheer oversight. Some days I am dumber than others...
>
> > And I do agree that this patch is much cleaner than my patch.
>
> Okay, Matthias, here's an updated version of that patch. The only
> difference is that it puts the usb_hcd_alloc_bandwidth() call _before_
> the usb_disable_interface() calls.
This time it worked. The HDD showed up after the echo.
Could the kernel automate this, like do what the echo triggers
automatically 1-2 seconds after it sees the error? I guess it's only
about 1 second or so that this HDD/enclosure-pair spins/boots up too
slow.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
