When implementing USB gadget on Odroid N2 I write descriptors for two endpoints so I get ep0, ep1 and ep2 files. I open those files and try to read from ep0 and ep2. While ep0 more or less works, for ep2 I get weird behaviour: the select() call returns 1 indicating that there is data to read and then read() call blocks. It happens even if I set the file descriptor to O_NONBLOCK. Here is the kernel log: https://pastebin.pl/view/aaa2d7f0
According to Synopsys's security policy, the link to the kernel log is blocked. Could you please attach the kernel log to this thread?
Created attachment 295653 [details] Dmesg
Created attachment 295655 [details] Dmesg, hopefully correct this time
According to dmesg, you use follow EP's: ep0in, ep0out, ep1in and ep1out. Why you refer to not used ep2?
The files that functionfs exposes are ep0 (for reading, events), ep1 (for writing, direction: to host) and ep2 (for reading, direction: to gadget). Not sure how and why they are named in dmesg. You can find the gadget configuration here: https://github.com/tomasz-grobelny/AACS/blob/master/AAServer/src/descriptors.cpp - line 75 and 84: .bEndpointAddress = 1 | USB_DIR_IN, .bEndpointAddress = 2 | USB_DIR_OUT, The code that fails/hangs is readWraper function here: https://github.com/tomasz-grobelny/AACS/blob/master/AAServer/src/AaCommunicator.cpp:493 select succeeds for ep2 and the read blocks. Exactly same function works ok for ep0 for all 3 hosts that I tested on and the code works fully ok for 2 out of 3 hosts that I tested on. I also know that in principle the 3rd host also should work because it works with other devices. Maybe lack of ep2 in the logs is something interesting?
I don't see any issue on dwc2 side based on driver debug logs - transfers are normally initiating and completing. Maybe something wrong in your function driver.
What do you mean by "function driver"? The userspace code that actually opens the ep0/ep1/ep2 files exposed by functionfs? It works correctly for other hosts. I don't have any more data to argue it is dwc2, but still seems like an issue in kernel USB subsystem. Another question that might help debugging it: is it the host that should open the ep2 endpoint? In other words: is it the host that is directly responsible for lack of any mention of ep2 in dmesg output after the device was reinitialized?
dwc2 in your case works as device. "It works correctly for other hosts." - do you mean "other devices"? Your userspace application work on host or device side?
No, I mean other hosts. I connect my Odroid N2 working as device (and this is were my userspace code comes into play) to different hosts and for some of them it works perfectly (Linux host running openauto, headunit in my car), for some it fails as described above (my brother's car, different manufacturer of the headunit). The car's headunit itself works fine as connecting a phone using the same android auto protocol works ok. I didn't (yet) have a chance to test on other hardware on device side. I am wondering whether this lack of ep2 communication is due to the host doing something or not doing something it should do.
I can't comment anything on other host sides, sorry.
Ok, clear. But anyway, looking at kernel side only: the ep2 was exposed by functionfs, it was successfully opened by my code, select returned that there is data available for reading and then read blocked. Something is not quite right here, unless I am missing something.