On Wed, Oct 2, 2013 at 9:14 AM, Sarah Sharp
<[email protected]> 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?
>
> 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.
>
> 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.
>
> Not sure why the Set Address with BSR=1 fails on a different system.
>
I found at least one bug yesterday. We don't accept USB3's
bMaxPacketSize0 == 9 as a valid device descriptor. That fixed the
initial setup context issue, but then it seemed like we ended up with
the toggle state mismatch you mention above.
if ((udev->speed == USB_SPEED_SUPER) &&
(le16_to_cpu(udev->descriptor.bcdUSB) < 0x0300)) {
dev_err(&udev->dev, "got a wrong device descriptor, "
"warm reset device\n");
--
Dan
--
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
