Message-ID: <20250520140936.08d72db6@booty>
Date: Tue, 20 May 2025 14:09:36 +0200
From: Luca Ceresoli <luca.ceresoli@...tlin.com>
To: Minas Harutyunyan <Minas.Harutyunyan@...opsys.com>
Cc: Alan Stern <stern@...land.harvard.edu>, "linux-usb@...r.kernel.org"
 <linux-usb@...r.kernel.org>, Kever Yang <kever.yang@...k-chips.com>, Greg
 Kroah-Hartman <gregkh@...uxfoundation.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, Hervé Codina
 <herve.codina@...tlin.com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>, Stefan Wahren <wahrenst@....net>, Fabrice
 Gasnier <fabrice.gasnier@...s.st.com>
Subject: Re: DWC2 gadget: unexpected device reenumeration on Rockchip RK3308

Hello Minas,

On Tue, 13 May 2025 07:35:40 +0000
Minas Harutyunyan <Minas.Harutyunyan@...opsys.com> wrote:

> >> I don't know anything about that driver, though.  Minas is the expert.
> >> You really need his advice.  
> > 
> > In the meanwhile I did two event captures, one with the mainline kernel
> > and one with the vendor kernel, using the same laptop setup and no hub
> > in between, and for each test I captured both the usbmon log and a
> > wireshark file. Both are available if needed.
> > 
> > By analyzing those captures I found that the communication between host
> > and gadget is almost identical. The only differenceis the get
> > configuration descriptor response has one more descriptor in the vendor
> > case (the working one). Here it is:
> > 
> > OTG Descriptor:
> >    bLength                 3
> >    bDescriptorType         9
> >    bmAttributes         0x03
> >      SRP (Session Request Protocol)
> >      HNP (Host Negotiation Protocol)
> > 
> > I don't know exacty what that implies, but for a quick test I went in
> > the mainline kernel and found that it can add the same descriptor if
> > both of these is true:
> > 
> >   * dr_mode = "otg" in device tree
> >   * "DWC2 Mode Selection" is "Dual role mode" in kconfig
> >     (i.e. CONFIG_USB_DWC2_DUAL_ROLE=y)
> > 
> > While I had:
> > 
> >   * dr_mode = "peripheral"
> >   * "DWC2 Mode Selection" = "Gadget only mode"
> >     (i.e. CONFIG_USB_DWC2_PERIPHERAL=y)
> > 
> > With those two changes the mainline kernel now behaves correctly, just
> > like the vendor kernel. No more disconnection after 5-6 seconds.
> > 
> > For the records, the vendor kernel already had dr_mode = "otg" and
> > CONFIG_USB_DWC2_DUAL_ROLE=y.
> > 
> > Based on my very limited knowledge of USB, intuitively it looks that:
> > 
> >   * in peripheral-only mode the OTG Descriptor should not be sent
> >   * in peripheral-only mode SRP does not make sense
> >   * in peripheral-only mode HNP does not make sense
> > 
> > Are the above correct?
> > 
> > Whether the answer, I think these new findings do not yet explain the
> > problem nor point to a correct solution. Apart from the added
> > descriptor, all of the initial enumeration events seen by usbmon is
> > identical in the two cases.
> > 
> > Minas, were you able to have a look at the info I collected?
> > Do they suggesting you anything about the dwc2 driver?
> >   
> Configuration parameters: CONFIG_USB_DWC2_HOST, 
> CONFIG_USB_DWC2_PERIPHERAL and CONFIG_USB_DWC2_DUAL_ROLE have impact 
> only on build process. Based on these parameters driver can build as 
> host only, device only or host + device.
> 
> OTG functionality of depend on:
> 1. On core configuration - GHWCFG2 bits 0:2:
> Mode of Operation (OtgMode)
> 3'b000: HNP- and SRP-Capable OTG (Host & Device)
> 3'b001: SRP-Capable OTG (Host & Device)
> 3'b010: Non-HNP and Non-SRP Capable OTG (Host and Device)
> 3'b011: SRP-Capable Device
> 3'b100: Non-OTG Device
> 3'b101: SRP-Capable Host
> 3'b110: Non-OTG Host
> Others: Reserved
> As you can see above, device only mode can support OTG, i.e. 
> "SRP-capable device".
> Based on provided OTG descriptor your core's OTG mode is equal to 0, 
> which means "HNP- and SRP-Capable OTG (Host & Device)".
> 2. Depend on platform (see dwc2/param.c) OTG functionality can be 
> updated, if it allowed by above core configuration OTG parameter.
> 3. OTG functionality can updated also through devicetree parameters 
> settings.

Thanks for the clarification. FYI the GHWCFG2 value is 0x228e2450 on
the RK3308, so OtgMode = "3'b000: HNP- and SRP-Capable OTG (Host &
Device)".

And I confirm the outcome of my tests:

 A) if dr_mode = "otg" in DT AND CONFIG_USB_DWC2_DUAL_ROLE=y:
    - OTG descriptor is sent
    - no disconnection, no re-enumeration

 B) if dr_mode = "peripheral" in DT OR CONFIG_USB_DWC2_PERIPHERAL=y:
    - OTG descriptor is not sent
    - disconnection+enumeration after ~6 seconds

The disconnection in case B should _not_ happen.

The presence/absence of the OTG descriptor is not wrong AFAICU. I'm
mentioning it just because it might give some clues.

I did a comparison of /sys/kernel/debug/usb/ff400000.usb/regdump in
cases A and B. The only relevant difference is that bit
USBOTG_GUSBCFG.ForceDevMode is 1 in case B. Based on the TRM, this
seems correct.

Doing other checks on registers and adding some logging to the code
showed everything appears to be configured correctly.

So, nothing explains why after about 6 seconds there is a disconnect.

My tests are done on mainline Linux v6.15-rc2.

Minas, do you have any hints or advice to understand why there is a
disconnect about ~6 seconds after a successful enumeration in gadget
mode?

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists