On Tue, 5 Feb 2008, Pete Zaitcev wrote:
> I think a proper patch would be welcome, because this is what
> Alan wrote:
>
> > As far as I can tell, Linux doesn't try to prevent high-speed devices
> > from using illegal maxpacket sizes. ehci-hcd should accept anything up
> > to 2047 without complaint.
>
> I interpret this as a) he forgot that we hardcoded 512 in qh_make
> and b) considers it right for us not to mess with whatever the
> descriptors on the device say (outside of sanity checks).
> If so, I agree.
a) is what happened. (Although it's not so much a matter of forgetting
as of not realizing it in the first place. I'm still not terribly
familiar with large parts of ehci-hcd.)
As for messing with descriptors sent by the device, we already do so --
although in ways that should be compatible with what the device seems
to expect. For a 1024-byte bulk maxpacket, we should at least log a
warning message.
There have been other cases where usbcore allows settings that the USB
spec considers illegal. The ones I can recall are:
Bulk endpoints for low-speed devices (the current code
actually changes the descriptor into an interrupt with
period 1);
Interrupt endpoints for low-speed devices with period
< 10 ms;
Periodic endpoints with other out-of-bounds period lengths
(the period is changed to something reasonable).
I don't see any reason not to accept high-speed bulk endpoints with
maxpacket other than 512 -- although such devices aren't guaranteed to
work correctly in all situations (for example, a scatter-gather buffer
might cross a page boundary at an odd multiple of 512 bytes).
As for what value to store in the QH header, we might as well accept
whatever value the device claims. In other words, use max_packet(maxp)
and don't hardcode it to 512, 1024, or anything else.
Alan Stern
-
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
