On Tue, Jan 5, 2021 at 2:07 PM Felipe Balbi [off-list ref] wrote:

Tomasz Grobelny [off-list ref] writes:

quoted

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