[PATCH] usb: cdns3: use VBUS Valid to determine role for dr_mode OTG

Siddharth Vadapalli s-vadapalli at ti.com
Thu Feb 12 11:57:45 CET 2026


Hello Marek,

On Thu, 2026-02-05 at 06:41 +0530, Siddharth Vadapalli wrote:
> On 04/02/26 7:39 PM, Marek Vasut wrote:
> > On 2/4/26 1:12 PM, Siddharth Vadapalli wrote:
> > > The cdns3_bind() function is responsible for identifying the appropriate
> > > driver to bind to the USB Controller's device-tree node. If the 
> > > device-tree
> > > node has the 'dr_mode' property set to 'otg', the existing approach fails
> > > to bind a driver, leading to loss of functionality.
> > > 
> > > To address this, use the VBUS Valid field of the OTG Status register to
> > > determine the role as follows:
> > > - If VBUS Valid field is set, it indicates that a USB Host is supplying
> > >    power and the Controller should assume the Peripheral role.
> > > - If VBUS Valid field is clear, it indicates the absence of a USB Host 
> > > and
> > >    the Controller should assume the Host role.
> > > 
> > > Additionally, when 'dr_mode' happens to be 'otg' and the STRAP settings
> > > are not specified, use VBUS Valid to determine the role in 
> > > cdns3_drd_init()
> > > and assign it to cdns->dr_mode.
> > > 
> > > Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
> > > ---
> > > 
> > > Hello,
> > > 
> > > This patch is based on commit
> > > a8d982e1f17 x86: cpu: Fix crash on FTRACE enabled builds
> > > of the master branch of U-Boot.
> > > 
> > > Patch has been tested in the context of USB DFU boot on the J784S4 SoC
> > > with a Cadence USB 3.0 Controller. Since the Linux device-tree for the
> > > J784S4-EVM specifies the 'dr_mode' as OTG, due to reuse of Linux
> > > device-tree by U-Boot, the 'dr_mode' of 'otg' causes USB DFU Boot to 
> > > fail.
> > > While one approach to fix it is to update 'dr_mode' to 'peripheral' in
> > > the 'k3-j784s4-u-boot.dtsi' file as a HACK, it doesn't scale to other
> > > SoCs and all of their 'u-boot.dtsi' files will have to be udpated as 
> > > well.
> > > While I am providing Texas Instruments SoCs as an example, I presume that
> > > SoCs from other vendors are also affected by the 'dr_mode' being 'otg'.
> > > This patch addresses the issue by using the VBUS Valid bit of the OTG
> > > status register to override 'dr_mode' from 'otg' to a deterministic role
> > > to enable functionality.
> > > 
> > > The USB DFU Boot Logs for the R5 SPL stage on J784S4 SoC with the current
> > > U-Boot master as of commit
> > > a8d982e1f17 x86: cpu: Fix crash on FTRACE enabled builds
> > > are:
> > > https://gist.github.com/Siddharth-Vadapalli-at-TI/ 
> > > b910f326b6c9fad760190bd299ae3ff3
> > > and the logs indicate that USB DFU Boot fails. The failure is 
> > > specifically
> > > due to 'dr_mode' being 'otg' and the cdns3_bind() function failing to 
> > > bind
> > > the device-tree node to the peripheral driver required for DFU Boot.
> > > 
> > > The USB DFU Boot Logs for the R5 SPL stage with just this patch applied
> > > while leaving 'dr_mode' at its existing value of 'otg' are:
> > > https://gist.github.com/Siddharth-Vadapalli-at- 
> > > TI/033b9772b6ab105b96806adf890848fe
> > > 
> > > Regards,
> > > Siddharth.
> > > 
> > >   drivers/usb/cdns3/core.c | 53 ++++++++++++++++++++++++++++++++++++++++
> > >   drivers/usb/cdns3/drd.c  | 11 +++++++++
> > >   2 files changed, 64 insertions(+)
> > > 
> > > diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
> > > index 4434dc15bec..b7be5c48fc9 100644
> > > --- a/drivers/usb/cdns3/core.c
> > > +++ b/drivers/usb/cdns3/core.c
> > > @@ -392,6 +392,55 @@ static const struct udevice_id cdns3_ids[] = {
> > >       { },
> > >   };
> > > +/*
> > > + * The VBUS Valid Bit in the OTG Status register can be used to 
> > > determine
> > > + * the role. When VBUS Valid is set, it indicates that a USB Host is 
> > > supplying
> > > + * power, so the Controller should assume the PERIPHERAL role. If it 
> > > isn't set,
> > > + * it indicates the absence of a USB Host, so the Controller should 
> > > assume the
> > > + * HOST role. If the OTG Status register is inaccessible, return OTG 
> > > role.
> > > + */
> > > +static enum usb_dr_mode cdns3_get_otg_mode(ofnode node)
> > > +{
> > > +    struct cdns3 cdns, *cdnsp;
> > > +    void __iomem *otg_regs;
> > > +    fdt_addr_t otg_addr;
> > > +    int otg_reg_index;
> > > +    int vbus;
> > > +
> > > +    otg_reg_index = ofnode_stringlist_search(node, "reg-names", "otg");
> > > +    if (otg_reg_index < 0)
> > > +        return USB_DR_MODE_OTG;
> > This is wrong, the function should return error and possibly mode via 
> > function parameter , do not conflate return value and mode please .
> 
> Regarding returning an error, the patch maintains status quo for the 
> case where we are unable to read the USB OTG Status register. Please 
> refer to the following diff in the patch:
> 
> 
> 	@@ -413,6 +462,10 @@ int cdns3_bind(struct udevice *parent)
>   		if (dr_mode == USB_DR_MODE_UNKNOWN)
>   			dr_mode = usb_get_dr_mode(dev_ofnode(parent));
> 
> 	+	/* Use VBUS Valid to determine role */
> 	+	if (dr_mode == USB_DR_MODE_OTG)
> 	+		dr_mode = cdns3_get_otg_mode(node);
> 	+
>   		switch (dr_mode) {
> 	 #if defined(CONFIG_SPL_USB_HOST) || \
>   		(!defined(CONFIG_XPL_BUILD) && defined(CONFIG_USB_HOST))
> 
> Only if the 'dr_mode' is already 'OTG', the newly added function 
> cdns3_get_otg_mode() is invoked. In case cdns3_get_otg_mode() cannot 
> determine the mode (otg status register cannot be read), we return otg 
> mode to maintain existing behavior, following which, the code will use 
> the CONFIGS to determine the role.
> 
> Returning an error will alter existing behavior rather than extending it 
> for enhancing functionality.
> 
> Regarding passing the mode via a function parameter, I could do so, but 
> I followed the implementation of other functions such as
> 	usb_get_dr_mode()
> which 'returns' the mode rather than using a function parameter to fill 
> in the mode.
> 
> Please let me know what you think.

Gentle reminder that I am waiting on your feedback. This patch has been
marked with the 'Changes Requested' state on patchworks:
https://patchwork.ozlabs.org/project/uboot/patch/20260204121245.2105523-1-s-vadapalli@ti.com/
although the discussion is still open.

Regards,
Siddharth.


More information about the U-Boot mailing list