Re: [PATCH v2 3/4] usb: chipidea: tegra: Avoid controller/PHY init if bus is externally controlled

[Svyatoslav Ryhel]

чт, 28 трав. 2026 р. о 10:23 Peter Chen (CIX) <peter.chen@xxxxxxxxxx> пише:
>
> On 26-05-25 17:43:42, Svyatoslav Ryhel wrote:
> > сб, 23 трав. 2026 р. о 11:30 Svyatoslav Ryhel <clamor95@xxxxxxxxx> пише:
> > >
> > > If the USB controller and PHY are externally controlled, then the
> > > registration of the controller and the PHY initialization should be
> > > skipped, since these configurations must be done by the device that
> > > controls the bus to work correctly.
> > >
> > > Since USB PHY in Tegra controls clock gates required by the controller
> > > itself, Chipidea core PHY management is not suitable for Tegra.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@xxxxxxxxx>
> > > ---
> > >  drivers/usb/chipidea/ci_hdrc_tegra.c | 32 ++++++++++++++++++----------
> > >  1 file changed, 21 insertions(+), 11 deletions(-)
> > >
> >
> > Hello there!
> >
> > This patch is required because I could not find an acceptable way to
> > manually remove and add a platform device. I will explain the details
> > below and hope that someone can give me some suggestions on how to
> > handle this situation.
> >
> > The Tegra USB controller is the root node, and it is bound and probed
> > automatically. This is perfectly fine for ordinary use cases. On the
> > other hand, the modem used in Tegra 3 devices requires the USB
> > controller to be registered at the exact moment when the modem is
> > ready to handle USB. If this window is not respected, the modem will
> > not expose the USB device, and all you get is a cascade of enumeration
> > failures.
>
> Could you add USB controller device node as the child node for modem,
> and dynamic creating USB controller device during modem probe?
>
> Peter
>

That might be an option, thank you! I have to tinker a bit this this.

Patch 1 of this sequence can be applied as it is.

Patches 2 and 3 should be dropped for now. There may be no need in them at all.

Patch 4 would be needed by modem, if it is appropriate to be applied,
I can resend patch 1 and 4 and that would be it.

> >
> > The solution as I see it right now: The modem has a power sequencing
> > driver, and the USB controller can either be autoprobed and
> > unregistered in the pseq probe and then registered/unregistered in the
> > on/off sequences, or it can have a status = "reserved" set in the USB
> > node and manually register/unregister it during the pseq on/off
> > sequences. This would eliminate the need for this patch.
> >
> > The problem I have faced is that I cannot properly and manually
> > control the USB controller driver to bind -> probe it and remove ->
> > unbind it from within powerseq.
> >
> > Help is appreciated. Thanks!
> >
> > Best regards,
> > Svyatoslav R.
>
> --
>
> Best regards,
> Peter