On Mon, Dec 27, 2010 at 09:32:25PM -0500, Alan Stern wrote:
> On Mon, 27 Dec 2010, Sarah Sharp wrote:
> > Is calling hub_port_logical_disconnect() if the xHCI driver can't
> > configure the hub structures correctly the right thing to do? At that
> > point, any low speed device plugged into the hub probably isn't going to
> > work, and I suspect any new children hubs won't work either.
>
> You'd lose all the devices already plugged into the hub. I suggest
> logging a dev_err message and continuing in a "degraded" mode.
Ok, I'll update the patch with that suggestion.
> > @@ -715,6 +717,23 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
> > usb_autopm_get_interface_no_resume(
> > to_usb_interface(hub->intfdev));
> > return; /* Continues at init2: below */
> > + } 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.
Sarah Sharp
--
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
