On Thu, 26 Jan 2023 at 15:27, Hans Petter Selasky <hps@xxxxxxxxxxx> wrote: > > On 1/26/23 14:59, Troels Liebe Bentsen wrote: > > On Thu, 26 Jan 2023 at 14:12, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > >>> > >>> I would like to change /sys/bus/usb/devices/usbX/descriptors so it never blocks. > >> > >> Patches gladly reviewed to do so :) > > Be careful. Been there done that for FreeBSD. You can cache the > descriptor in memory - yes, but beware that the values inside the device > descriptor may change after re-enumerating the device via software, like > firmware upgrade, and that directly hits on the XHCI controller > programming, that you need to load and configure the new bMaxPacketSize > in there! > > And the same goes for the other fields in there :-) It actually looks like a lot of the other files in sysfs are cached already, fx. /sys/bus/usb/devices/x-x.x/manufacturer We tried changing the manufacturer name after our hardware was booted and using the Linux usb gadget driver and only libusb seemed to be able to see the change. But that's another question, how do I get Linux to re-enumerating the device and update the sysfs files? > > > > > We will have a look and get back to you. > > It's probably best to find the undocumented bits of your USB peripheral > controller first! With USB control transactions I've seen so much > craziness over the years you won't believe it. The only ones that get it > right, is the ones that lay out all USB control endpoint jobs in memory > via DMA descriptors. All the ones that simply use a few registers to > receive the SETUP packet, DATA and status ZLP, have undocumented races. > By races I mean, what happens if you get SETUP and DATA interrupt bits > at the same time, or maybe all three, what is the right order, or what > about STALL conditions and short control transfers and blah blah blah. > This thing can really blow your mind, but yeah, many device side > programmers simply use the example code they get from the vendor and > give a shit about anything that can later go wrong. That is my simple > impression so far in the USB world. > It's an i.MX6 and built in microcode that runs the USB in flash mode, but we are quite sure it's a power sequencing issue that hangs the CPU in I.MX6. So bad hardware design and not NPX this time, we have had plenty of other issues, but this time it does not seem to be their fault. Also we have some other designs with i.MX6 and don't have the issue there. Regards Troels > --HPS > > > > >> > >> thanks, > >> > >> greg k-h > > > > Regards Troels >
