Re: [PATCH] [RFC] usb: Do not attempt to reset the device while itis disabled

[Sarah Sharp]

On Tue, May 31, 2011 at 07:41:14PM +0200, Maarten Lankhorst wrote:
> Hi Sarah,
> 
> Op 31-05-11 19:14, Sarah Sharp schreef:
> > On Tue, May 31, 2011 at 03:47:18PM +0200, Maarten Lankhorst wrote:
> > Can you send me the full dmesg with CONFIG_USB_XHCI_HCD_DEBUGGING turned
> > on?  I'd like to see the full debug log for this and see if the host or
> > driver is falling over in an earlier spot.
> I'm on linux 2.6.39, relevant dmesg spits out this:

Do you also have CONFIG_USB_DEBUGGING turned on and have you run `sudo
dmesg -n 8`?  There should be much more debugging here.

> >> Signed-off-by: Maarten Lankhorst<m.b.lankhorst@xxxxxxxxx>
> >>
> >> ---
> >> index 81b976e..9a869b2 100644
> >> --- a/drivers/usb/host/xhci.c
> >> +++ b/drivers/usb/host/xhci.c
> >> @@ -2307,6 +2307,10 @@ int xhci_discover_or_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
> >>  			return -EINVAL;
> >>  	}
> >>
> >> +	if (GET_SLOT_STATE(xhci_get_slot_ctx(xhci, virt_dev->out_ctx)->dev_state) == 0&&
> >> +	    (xhci_get_ep_ctx(xhci, virt_dev->out_ctx, 0)->ep_info&  EP_STATE_MASK) == EP_STATE_DISABLED)
> >> +		return 0;
> >> +
> > Why are you looking at the endpoint state?  The control endpoint state
> > has nothing to do with the outcome of the Reset Device command.  The
> > host controller is only allowed to reject the command if the device slot
> > is not in the addressed or configured state (according to the 0.96 spec,
> > I assume this host isn't a 1.0 host).  So the control endpoint state
> > should have nothing to do with whether the command succeeds.
> >
> > I'm also confused as to why this code works.  The control endpoint is
> > never disabled until the USB core deallocates a device.  Once the xHCI
> > driver allocates a slot and issues an Address Device command, the
> > control endpoint's output context should move from the disabled state to
> > the running state.  But if this conditional actually ran, then either
> > the host controller didn't update the output context for the control
> > endpoint, the Address Device command failed, or something very strange
> > is going on.
> >
> > Full dmesg with the xHCI driver debug will help me figure this out.
> > What kernel are you running?
> I think it happens because hub_port_reset is called in hub_port_init since
> commit 07194ab7be63a972096309ab0ea747df455c6a20, so I'd say that is
> what causes the reset to be called in this state?

Yes, but every host controller I've run into, except yours, can handle
this patch, and the xHCI specification says the host should be able to
handle this, so my inclination is that your hardware is just broken.

I'd like to know exactly which host controller it is (`lspci -vvv` will
help with that), and then we can hopefully track down an engineer from
that company and ask them what that error code means.  Once we do
receive confirmation that the error code is just a fluke, we can create
a quirk for that specific host controller to ignore that error condition
for the reset device command.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/