dwc2 gadget mode different behaviour with different hosts

dwc2 gadget mode different behaviour with different hosts

[Tomasz Grobelny]

Hi all,

I am trying to implement Android Open Accessory Protocol which is a
base for Android Auto Protocol. I am using Odroid N2 working in gadget
mode and trying to send data to car's headunit.

The problem I am facing now is that for some headunits it works, for
some it doesn't. It seems there is some difference in what happens
immediately after the host tries to switch device to accessory mode by
sending control commands 51, 52 and 53. The initial part in all cases
(all headunits I have access to) works just fine, but after it
completes my Odroid gadget should be reinitialized on the USB bus. On
hosts on which it works (my PC and VW headunit) the device gets new
address like this:

[   33.491312] Mass Storage Function, version: 2009/09/11
[   33.491322] LUN: removable file: (no medium)
[   33.504716] file system registered
[   33.506279] read descriptors
[   33.506290] read strings
[   33.510164] dwc2 ff400000.usb: bound driver configfs-gadget
[   33.678710] dwc2 ff400000.usb: new device is high-speed
[   33.750089] dwc2 ff400000.usb: new device is high-speed
[   33.806366] dwc2 ff400000.usb: new address 4
[   37.899601] ffs_data_put(): freeing
[   37.899862] unloading
[   38.942619] file system registered
[   38.943003] read descriptors
[   38.943009] read strings
[   38.946561] dwc2 ff400000.usb: bound driver configfs-gadget
[   39.310762] dwc2 ff400000.usb: new device is high-speed
[   39.381890] dwc2 ff400000.usb: new device is high-speed
[   39.438056] dwc2 ff400000.usb: new address 5

On Fiat's headunit I get the same address for both phases:
[   33.773387] Mass Storage Function, version: 2009/09/11
[   33.773397] LUN: removable file: (no medium)
[   33.784054] file system registered
[   33.792335] read descriptors
[   33.792389] read strings
[   33.796349] dwc2 ff400000.usb: bound driver configfs-gadget
[   34.023544] dwc2 ff400000.usb: new device is high-speed
[   34.131592] dwc2 ff400000.usb: new device is high-speed
[   34.194740] dwc2 ff400000.usb: new address 3
[   34.353478] ffs_data_put(): freeing
[   34.353825] unloading
[   35.392723] file system registered
[   35.393450] read descriptors
[   35.393459] read strings
[   35.403955] dwc2 ff400000.usb: bound driver configfs-gadget
[   37.119299] dwc2 ff400000.usb: new device is high-speed
[   37.227341] dwc2 ff400000.usb: new device is high-speed
[   37.290497] dwc2 ff400000.usb: new address 3

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)?

Best regards,
Tomasz Grobelny

Re: dwc2 gadget mode different behaviour with different hosts

[Greg KH]

On Tue, Jan 05, 2021 at 02:02:16AM +0100, Tomasz Grobelny wrote:
> Hi all,
> 
> I am trying to implement Android Open Accessory Protocol which is a
> base for Android Auto Protocol. I am using Odroid N2 working in gadget
> mode and trying to send data to car's headunit.
> 
> The problem I am facing now is that for some headunits it works, for
> some it doesn't. It seems there is some difference in what happens
> immediately after the host tries to switch device to accessory mode by
> sending control commands 51, 52 and 53. The initial part in all cases
> (all headunits I have access to) works just fine, but after it
> completes my Odroid gadget should be reinitialized on the USB bus. On
> hosts on which it works (my PC and VW headunit) the device gets new
> address like this:
> 
> [   33.491312] Mass Storage Function, version: 2009/09/11
> [   33.491322] LUN: removable file: (no medium)
> [   33.504716] file system registered
> [   33.506279] read descriptors
> [   33.506290] read strings
> [   33.510164] dwc2 ff400000.usb: bound driver configfs-gadget
> [   33.678710] dwc2 ff400000.usb: new device is high-speed
> [   33.750089] dwc2 ff400000.usb: new device is high-speed
> [   33.806366] dwc2 ff400000.usb: new address 4
> [   37.899601] ffs_data_put(): freeing
> [   37.899862] unloading
> [   38.942619] file system registered
> [   38.943003] read descriptors
> [   38.943009] read strings
> [   38.946561] dwc2 ff400000.usb: bound driver configfs-gadget
> [   39.310762] dwc2 ff400000.usb: new device is high-speed
> [   39.381890] dwc2 ff400000.usb: new device is high-speed
> [   39.438056] dwc2 ff400000.usb: new address 5
> 
> On Fiat's headunit I get the same address for both phases:
> [   33.773387] Mass Storage Function, version: 2009/09/11
> [   33.773397] LUN: removable file: (no medium)
> [   33.784054] file system registered
> [   33.792335] read descriptors
> [   33.792389] read strings
> [   33.796349] dwc2 ff400000.usb: bound driver configfs-gadget
> [   34.023544] dwc2 ff400000.usb: new device is high-speed
> [   34.131592] dwc2 ff400000.usb: new device is high-speed
> [   34.194740] dwc2 ff400000.usb: new address 3
> [   34.353478] ffs_data_put(): freeing
> [   34.353825] unloading
> [   35.392723] file system registered
> [   35.393450] read descriptors
> [   35.393459] read strings
> [   35.403955] dwc2 ff400000.usb: bound driver configfs-gadget
> [   37.119299] dwc2 ff400000.usb: new device is high-speed
> [   37.227341] dwc2 ff400000.usb: new device is high-speed
> [   37.290497] dwc2 ff400000.usb: new address 3
> 
> 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)?

Why does it matter what USB "address" your device gets?  That's a random
number that nothing should care about as the USB spec allows it to be
reused if the host controller wants to.

What requires a "different" address each time?  Shouldn't that userspace
bug be fixed instead?

thanks,

greg k-h

Re: dwc2 gadget mode different behaviour with different hosts

[Tomasz Grobelny]

On Tue, Jan 5, 2021 at 7:49 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Jan 05, 2021 at 02:02:16AM +0100, Tomasz Grobelny wrote:
> > 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)?
>
> Why does it matter what USB "address" your device gets?  That's a random
> number that nothing should care about as the USB spec allows it to be
> reused if the host controller wants to.
>
Not that I know 100% it matters, but until now this is the only
observable difference in dmesg. It is just my guess that something
might have gone wrong with reinitialization. Also see other questions
how to debug this.

> What requires a "different" address each time?  Shouldn't that userspace
> bug be fixed instead?
>
The userspace code does not require different address, not even sure
it could get one via functionfs.

Best regards,
Tomasz Grobelny

Re: dwc2 gadget mode different behaviour with different hosts

[Felipe Balbi]

Hi,

Tomasz Grobelny <tomasz.aleksander.grobelny@gmail.com> writes:
> Hi all,
>
> I am trying to implement Android Open Accessory Protocol which is a
> base for Android Auto Protocol. I am using Odroid N2 working in gadget
> mode and trying to send data to car's headunit.
>
> The problem I am facing now is that for some headunits it works, for
> some it doesn't. It seems there is some difference in what happens
> immediately after the host tries to switch device to accessory mode by
> sending control commands 51, 52 and 53. The initial part in all cases
> (all headunits I have access to) works just fine, but after it
> completes my Odroid gadget should be reinitialized on the USB bus. On
> hosts on which it works (my PC and VW headunit) the device gets new
> address like this:
>
> [   33.491312] Mass Storage Function, version: 2009/09/11
> [   33.491322] LUN: removable file: (no medium)
> [   33.504716] file system registered
> [   33.506279] read descriptors
> [   33.506290] read strings
> [   33.510164] dwc2 ff400000.usb: bound driver configfs-gadget
> [   33.678710] dwc2 ff400000.usb: new device is high-speed
> [   33.750089] dwc2 ff400000.usb: new device is high-speed
> [   33.806366] dwc2 ff400000.usb: new address 4
> [   37.899601] ffs_data_put(): freeing
> [   37.899862] unloading
> [   38.942619] file system registered
> [   38.943003] read descriptors
> [   38.943009] read strings
> [   38.946561] dwc2 ff400000.usb: bound driver configfs-gadget
> [   39.310762] dwc2 ff400000.usb: new device is high-speed
> [   39.381890] dwc2 ff400000.usb: new device is high-speed
> [   39.438056] dwc2 ff400000.usb: new address 5
>
> On Fiat's headunit I get the same address for both phases:
> [   33.773387] Mass Storage Function, version: 2009/09/11
> [   33.773397] LUN: removable file: (no medium)
> [   33.784054] file system registered
> [   33.792335] read descriptors
> [   33.792389] read strings
> [   33.796349] dwc2 ff400000.usb: bound driver configfs-gadget
> [   34.023544] dwc2 ff400000.usb: new device is high-speed
> [   34.131592] dwc2 ff400000.usb: new device is high-speed
> [   34.194740] dwc2 ff400000.usb: new address 3
> [   34.353478] ffs_data_put(): freeing
> [   34.353825] unloading
> [   35.392723] file system registered
> [   35.393450] read descriptors
> [   35.393459] read strings
> [   35.403955] dwc2 ff400000.usb: bound driver configfs-gadget
> [   37.119299] dwc2 ff400000.usb: new device is high-speed
> [   37.227341] dwc2 ff400000.usb: new device is high-speed
> [   37.290497] dwc2 ff400000.usb: new address 3
>
> 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.

-- 
balbi

Re: dwc2 gadget mode different behaviour with different hosts

[Tomasz Grobelny]

On Tue, Jan 5, 2021 at 2:07 PM Felipe Balbi <balbi@kernel.org> wrote:
> Tomasz Grobelny <tomasz.aleksander.grobelny@gmail.com> 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