On 11/26/2014 10:40 PM, Alan Stern wrote: > On Wed, 26 Nov 2014, Sebastian Andrzej Siewior wrote: > >> On 11/26/2014 04:24 PM, Alan Stern wrote: >>>> On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote: >>>>> The max packet size within the FS descriptor has to be highest possible >>>>> value and _not_ the one that is (or will be) used on FS. >>>> >>>> The current code sets wMaxPacketSize of FS interrupt endpoint descriptor >>>> as 64, which is in accordance with the usb 2.0 specification, section 5.7.3 >>>> >>>> The maximum allowable interrupt data payload size is 64 bytes >>>> or less for full-speed. High-speed endpoints are allowed >>>> maximum data payload sizes up to 1024 bytes. >>> >>> The real problem is that we are assuming endpoints can be allocated in >>> a single way that will work correctly for all possible connection >>> speeds. (I suspect it was done this way out of laziness and a desire >>> to minimize the code size.) This assumption is obviously incorrect >>> when the hardware has an interrupt endpoint that supports packet sizes >>> of 64 but no larger. >> >> The code will check properly if you pass 1024 and check the size >> accordingly. You have to "downsize" your FS descriptor later. This >> function will only fail to do this if your gadget isn't dual speed. In >> that case it expects 64 as the upper limit for INT (if I recall >> correctly). > > It will also fail in situations where you use up a lot of endpoints. > For example, let's say the UDC only supports 4 endpoints, one of which > must have a maxpacket value <= 64. If you want to have four interrupt > endpoints, you can't run at high speed -- but you can run at full > speed. However, the approach you outlined above won't allow it. fair enough. So we could try to look for one with 1024 and it fails we could re-try with 512 and then 64. If all three fail we would continue without INT support. >> Ah. And endpoints are never returned to the allocator. Some gadgets set >> ->private to NULL, other just ignore it and let the core do it. So >> re-doing the endpoint allocator is probably the right thing to do. And > > The allocator doesn't need to be changed. We already have a > usb_ep_autoconfig_reset() function. yes, that one that frees them all. >> then force every gadget to allocate an endpoint for FS/HS/SS and give >> it back _and_ please edit the copy of the descriptor and not the global >> "original". > > Yes. > >> But the work will not be done before we have the next release is out >> and as of now it breaks g_zero on musb, net2280 and maybe others. > > Felipe will have to decide how to handle this. > > Alan Stern > Sebastian -- 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
