On Thu, 24 Sep 2015, Steinar H. Gunderson wrote: > On Thu, Sep 24, 2015 at 11:22:57AM -0400, Alan Stern wrote: > >> I assume there's no way I can lie to the chip? Like, if I know for a fact > >> that the card will send less data than the alternate claims (like, > >> I'm using a video mode that will require only a few hundred megabits/second > >> in practice, but even the lowest alternate claims >1 Gbit/sec). > > You can always patch the kernel to do whatever you want. For instance, > > you could reduce the bMaxBurst value in the descriptor after the kernel > > gets it from the card. Short of that, there is no way to affect the > > outcome. > > I tried, but it didn't work; I bMaxBurst to 4 instead of to 15 > (in usb_parse_ss_endpoint_companion). It didn't change the outcome. > Perhaps this doesn't actually change what the xHCI controller sees, > though.
It does. Grep for max_burst in drivers/usb/host/x*.c to see where it gets used. (Note that in a couple of places involving USB-2 devices, the code uses max_burst where it really means multiplicity.) 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
