On Wed, 2 Oct 2013, Sarah Sharp wrote:
> On Mon, Sep 23, 2013 at 04:29:40PM -0700, Dan Williams wrote:
> > Change the enumeration scheme for xhci attached devices from:
> >
> > SetAddress
> > GetDescriptor(8)
> > GetDescriptor(18)
> >
> > ...to:
> >
> > GetDescriptor(64)
> > SetAddress
> > GetDescriptor(18)
>
> Thinking about this sequence again, I'm trying to figure out if that
> first 64-byte descriptor fetch is going to be an issue. We set up the
> control endpoint context with a max packet size of 8 bytes, but it can
> be larger, depending on the device. We don't know what it is until we
> fetch the device descriptors.
>
> So if the USB core asks for 64-bytes of the device descriptor before the
> xHCI driver sets the real max packet size in the control endpoint
> context, won't the host controller expect to receive 8-byte packets, but
> may instead get larger packets?
>
> Alan, how would this work under EHCI?
We start out by assuming the maxpacket size is 64 bytes -- that's what
we tell the host controller. What happens during the actual transfer
then depends on the device:
If the maxpacket size really is 32 or 64 then the device
sends the entire 18-byte device descriptor in a single packet
and the transaction completes normally.
If the maxpacket size really is 16 bytes then the device sends
the first 16 bytes of the device descriptor in a single packet.
The controller thinks this "short" packet indicates the end of
the data stage, so it goes directly to the status stage and
the transaction ends early.
The same sort of thing happens if the maxpacket size really is
8 bytes, except that the device sends just the first 8 bytes
of the device descriptor in a single packet.
The early terminations might leave the device in an indeterminate
state, so the next thing we do is a reset. But no matter what, we end
up with a valid copy of at least the first 8 bytes of the device
descriptor, which is all we need to determine the actual maxpacket
size.
> Dan, I was also testing under HSW-ULT with a (possibly buggy) device,
> and I managed to get the device context into a bad state. The device
> refused to respond to the first 64-byte control transfer (it timed out
> three times), and then the USB core reset the device. The xHCI driver
> then attempted to issue a Reset Device command, which failed because the
> device was in the default state.
You ought to be able to reset a device while it's in the Default state.
Why should xHCI disallow this?
As I understand section 4.6.11 in the xHCI spec, the Reset Device
command merely tells the controller that the device has already been
reset -- it doesn't actually perform the reset itself.
> I think this meant the endpoint toggles in the control endpoint on the
> device were mis-matched to the host's toggle state. That would cause
> protocol errors. I'm not quite sure what the solution for this is yet,
> but I think it may be why you get the context state error on the second
> Set Address command. Because the Reset Device command didn't complete
> successfully, the host thinks the device is still in the default state.
At that point, the device really _was_ in the Default state.
> Not sure why the Set Address with BSR=1 fails on a different system.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
