Linux Tegra architecture development
 help / color / mirror / Atom feed
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

  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