Re: [PATCH 3/5] phy: tegra: xusb: Fix ordering issue when switching roles on USB2 ports

[Jon Hunter]

On 13/01/2026 15:10, Diogo Ivo wrote:

...

> > > > > -    if (tegra->host_mode)
> > > > > -        phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_HOST);
> > > > > -    else
> > > > > -        phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_NONE);
> > > > > +    if (tegra->host_mode) {
> > > > > +        if (!tegra_xusb_usb2_port_wait_role_none(tegra->padctl,
> > > > > +                             tegra->otg_usb2_port))
> > > > > +            return;
> > > > > +        role = USB_ROLE_HOST;
> > > > > +    }
> > > > > +
> > > > > +    mutex_lock(&tegra->lock);
> > > > > +    phy_set_mode_ext(phy, PHY_MODE_USB_OTG, role);
> > > > >       mutex_unlock(&tegra->lock);
> > > >
> > > > I am trying to understand why you opted to implement it this way 
> > > > around and not add the wait loop after setting to the mode to 
> > > > USB_ROLE_NONE in the original code all within the context of the mutex?
> > >
> > > I did that to minimize the amount of time we wait while holding the
> > > mutex, as we can now possibly wait a significant amount of time for the
> > > role switch. Is this an unneccessary optimization?
> >
> > Do you mean it will be longer than a few 100us?
>
> Currently the worst case in wait_role_none() is around 300us but again
> this is simply because I chose the values with no criteria except that
> in my testing they have worked thus far. Do you have access to any
> internal documentation where the transition length is documented?
>
> In any case I think that the underlying principle of minimizing the time
> we hold the mutex is solid, no?

Yes, but it was unclear to me if there could be a case where we are 
waiting for USB_ROLE_NONE but we have already transitioned to host. May 
be that will never happen, but it was not clear.

Jon

--
nvpublic