Hello, On Tue, Jan 24, 2017 at 12:20 AM, Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> wrote: > Seems like HW engineer wanted these last few endpoints to *not* support > full USB3 packets. They are probably supposed to be used for Isochronous > and/or Interrupts endpoints. At some point we need to support this as > well. During initialization we should read FIFO size configuration and > extract wMaxPacketSize for $endpoint from the HW. If my understanding of your register explanation is correct, the >9 IN endpoints could still work as bulk in LS/FS speeds (I don't have the board at hand to try right now). If this is correct, won't your patch (in your testing/next branch) make these endpoints unusable for bulk use even in LS/FS ? A bit more generally, I have the feeling (from reading epautoconf.c and f_fs.c) that the endpoint dispatching (and hence, endpoint capabilities) lacks the notion of speed (SS has it, kind of, via the companion descriptor argument in epautoconf.c). I noticed something a few weeks back which may come from this lack: when I tried only populating the HS descriptors, the host xHCI would complain about non-standard endpoint size (64B instead of HS-required 512B). In my understanding, this is because f_fs.c allocates endpoints using the first populated descriptor set (in LS/FS, then HS, then SS order), and epautoconf.c overwriting the buffer size to 64 on non-SS bulk descriptors. I think extending such API is over my head still. Do you have ideas on this ? FWIW, the Intel Edison (the board I'm using as device) is not USB 3 capable despite dwc3 usage. If my undrstanding is correct, it is because it lacks the USB 3 companion phy, and of course does not expose the corresponding tracks on the expansion connector (would it be possible to host the companion outside the edison module ? I have no idea how it is supposed to interract with the dwc3 and USB 2 phy). Regards, -- Vincent Pelletier -- 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
