On Tue, Jan 5, 2021 at 2:07 PM Felipe Balbi <balbi@xxxxxxxxxx> wrote: > Tomasz Grobelny <tomasz.aleksander.grobelny@xxxxxxxxx> writes: > > Any idea why this might be the case? Can I somehow enforce that the > > device reintroduces itself on the bus and gets new address? Can I > > somehow debug what happens when my device is connected as gadget (eg. > > see control messages for device/configuration/string descriptors)? > > Make sure your device passed USB Command Verifier Chapter 9 tests. You > can use mass storage for early testing, once that's working fine, then > switch to the android accessory mode. This could very well be a bug in > dwc2 itself. > Indeed there was an issue with passing chapter 9 tests, but fixing it didn't fix the main issue. I had a chance to do more testing on the offending headunit (USB host) and I found out that something weird happens with read call. After switching to accessory mode I open 3 descriptors (ep0, ep1 and ep2). On ep0 and ep2 I run readWrapper function in a loop. The readWrapper is a pretty standard select+read combo to implement interruptible read. However, while it works for ep0 - the select either receives data or times out - for ep2 the select returns 1 (which indicates there is data to read) and then read call blocks. Even more weird is that it blocks when O_NONBLOCK option is set for ep2 fd. Doesn't it look like a kernel bug? If not, where to look for issues in my code? Note that the same code works for other headunits and obviously this specific headunit works correctly with other devices. Next thing to try is another SBC, like RPi4 with different USB controller, but this might take another two months :-) dmesg fragment here: https://pastebin.pl/view/aaa2d7f0 Best regards, Tomasz Grobelny
