From: "Peter Chen (CIX)" <peter.chen@kernel.org>
To: Svyatoslav Ryhel <clamor95@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Thierry Reding <thierry.reding@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
Xu Yang <xu.yang_2@nxp.com>, Peng Fan <peng.fan@nxp.com>,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/4] usb: chipidea: tegra: Avoid controller/PHY init if bus is externally controlled
Date: Thu, 28 May 2026 15:23:39 +0800 [thread overview]
Message-ID: <ahfte9D4TsbgzFQx@nchen-desktop> (raw)
In-Reply-To: <CAPVz0n0jpnPFh0f=CWHufzZ+e24xsem5DFTKdFu6sczCLk08Fg@mail.gmail.com>
On 26-05-25 17:43:42, Svyatoslav Ryhel wrote:
> сб, 23 трав. 2026 р. о 11:30 Svyatoslav Ryhel <clamor95@gmail.com> пише:
> >
> > 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@gmail.com>
> > ---
> > 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
>
> 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
next prev parent reply other threads:[~2026-05-28 7:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-23 8:30 [PATCH v2 0/4] usb: chipidea: tegra: Add external control option Svyatoslav Ryhel
2026-05-23 8:30 ` [PATCH v2 1/4] dt-bindings: usb: Move Tegra-specific Chipidea USB properties into a dedicated schema Svyatoslav Ryhel
2026-05-23 8:30 ` [PATCH v2 2/4] dt-bindings: usb: chipidea,usb2-tegra: Document nvidia,external-control property Svyatoslav Ryhel
2026-05-23 8:30 ` [PATCH v2 3/4] usb: chipidea: tegra: Avoid controller/PHY init if bus is externally controlled Svyatoslav Ryhel
2026-05-25 14:43 ` Svyatoslav Ryhel
2026-05-28 7:23 ` Peter Chen (CIX) [this message]
2026-05-28 11:12 ` Svyatoslav Ryhel
2026-05-23 8:30 ` [PATCH v2 4/4] usb: chipidea: tegra: Expose tegra_usb structure Svyatoslav Ryhel
2026-05-29 14:57 ` [PATCH v2 0/4] usb: chipidea: tegra: Add external control option Svyatoslav Ryhel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ahfte9D4TsbgzFQx@nchen-desktop \
--to=peter.chen@kernel.org \
--cc=clamor95@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peng.fan@nxp.com \
--cc=robh@kernel.org \
--cc=thierry.reding@kernel.org \
--cc=xu.yang_2@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox