On Tue, 28 Dec 2010, Sarah Sharp wrote:
> > > + } else if (type == HUB_RESET_RESUME) {
> > > + /* The internal host controller state for the hub device
> > > + * may be gone after a host power loss on system resume.
> > > + * Update the device's info so the HW knows it's a hub.
> > > + */
> > > + hcd = bus_to_hcd(hdev->bus);
> > > + if (hcd->driver->update_hub_device) {
> > > + ret = hcd->driver->update_hub_device(hcd, hdev,
> > > + &hub->tt, GFP_KERNEL);
> >
> > Isn't this supposed to be GFP_NOIO?
>
> So hub reset resume may happen as part of mass storage error handling?
> I thought GFP_NOIO would only be necessary when
> usb_reset_and_verify_device() was called with a storage device? I can't
> quite picture the sequence of events that would cause the kernel to try
> to flush pending IO when a hub is being reset, and that would cause a
> deadlock.
I'm far from certain about this; it would be best to check with Oliver.
My thought was that you might have a suspended mass-storage device
beneath a suspended hub. A runtime resume of the storage device would
cause the hub to resume as well, but I guess it would never be a
reset-resume. So it looks like my thought was wrong.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
