From: sashiko-bot@kernel.org
To: "Svyatoslav Ryhel" <clamor95@gmail.com>
Cc: conor+dt@kernel.org, neil.armstrong@linaro.org, vkoul@kernel.org,
krzk+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org,
olteanv@gmail.com, linux-phy@lists.infradead.org
Subject: Re: [PATCH v1 2/6] usb: chipidea: tegra: Avoid controller/PHY init if bus is externally controlled
Date: Tue, 12 May 2026 23:29:48 +0000 [thread overview]
Message-ID: <20260512232949.35D5AC2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260511135703.62470-3-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unbinding the `tegra_usb` driver when `nvidia,external-control` is present causes a NULL pointer dereference.
- [Medium] Unconditional call to `usb_phy_shutdown()` in `tegra_usb_remove()` on an uninitialized PHY triggers a kernel warning.
--
commit 3826697c3ab50338add8e2c889c119f3dae6b570
Author: Svyatoslav Ryhel <clamor95@gmail.com>
usb: chipidea: tegra: Avoid controller/PHY init if bus is externally controlled
If the USB controller and PHY are externally controlled, the registration
of the controller and the PHY initialization are skipped. This delegates
configuration to the device that controls the bus.
> diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c b/drivers/usb/chipidea/ci_hdrc_tegra.c
> index 372788f0f9701..593390a818d12 100644
> --- a/drivers/usb/chipidea/ci_hdrc_tegra.c
> +++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
[ ... ]
> @@ -342,12 +348,14 @@ static int tegra_usb_probe(struct platform_device *pdev)
> if (of_usb_get_phy_mode(pdev->dev.of_node) == USBPHY_INTERFACE_MODE_ULPI)
> usb->data.flags &= ~CI_HDRC_SUPPORTS_RUNTIME_PM;
>
> - usb->dev = ci_hdrc_add_device(&pdev->dev, pdev->resource,
> - pdev->num_resources, &usb->data);
> - if (IS_ERR(usb->dev)) {
> - err = dev_err_probe(&pdev->dev, PTR_ERR(usb->dev),
> - "failed to add HDRC device");
> - goto phy_shutdown;
> + if (!usb->externally_controlled) {
> + usb->dev = ci_hdrc_add_device(&pdev->dev, pdev->resource,
> + pdev->num_resources, &usb->data);
> + if (IS_ERR(usb->dev)) {
> + err = dev_err_probe(&pdev->dev, PTR_ERR(usb->dev),
> + "failed to add HDRC device");
> + goto phy_shutdown;
> + }
> }
>
> return 0;
When nvidia,external-control is present, usb->dev is left uninitialized
and remains NULL. Does the unbind path still try to use it?
Looking at tegra_usb_remove(), it unconditionally calls
ci_hdrc_remove_device() with usb->dev:
static void tegra_usb_remove(struct platform_device *pdev)
{
struct tegra_usb *usb = platform_get_drvdata(pdev);
ci_hdrc_remove_device(usb->dev);
...
This looks like it could lead to a NULL pointer dereference, as
ci_hdrc_remove_device() dereferences the pointer immediately without checking:
void ci_hdrc_remove_device(struct platform_device *pdev)
{
int id = pdev->id;
...
Could this regression cause a crash on device unbind or module removal
when the controller is externally controlled?
Additionally, when the PHY initialization is skipped during probe, does
tegra_usb_remove() still attempt to shut it down?
static void tegra_usb_remove(struct platform_device *pdev)
{
...
usb_phy_shutdown(usb->phy);
...
Since the PHY wasn't initialized, its frequency will be 0. Calling
tegra_usb_phy_shutdown() on this uninitialized PHY appears to trigger
a warning regression:
static void tegra_usb_phy_shutdown(struct usb_phy *u_phy)
{
struct tegra_usb_phy *phy = to_tegra_usb_phy(u_phy);
if (WARN_ON(!phy->freq))
return;
...
Should tegra_usb_remove() be updated to check if it is externally
controlled before calling the shutdown and remove functions?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260511135703.62470-1-clamor95@gmail.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-05-12 23:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 13:56 [PATCH v1 0/6] Add support for Infineon/Intel XMM6260 modem Svyatoslav Ryhel
2026-05-11 13:56 ` [PATCH v1 1/6] dt-bindings: usb: ci-hdrc-usb2: Document nvidia,external-control property Svyatoslav Ryhel
2026-05-12 23:29 ` sashiko-bot
2026-05-11 13:56 ` [PATCH v1 2/6] usb: chipidea: tegra: Avoid controller/PHY init if bus is externally controlled Svyatoslav Ryhel
2026-05-12 1:15 ` Peter Chen (CIX)
2026-05-12 6:13 ` Svyatoslav Ryhel
2026-05-12 7:51 ` Peter Chen (CIX)
2026-05-12 9:14 ` Svyatoslav Ryhel
2026-05-12 23:29 ` sashiko-bot [this message]
2026-05-11 13:56 ` [PATCH v1 3/6] dt-bindings: net: Document Infineon/Intel XMM6260 modem Svyatoslav Ryhel
2026-05-12 23:29 ` sashiko-bot
2026-05-11 13:56 ` [PATCH v1 4/6] net: usb: Add Infineon XMM6260 Baseband modem support Svyatoslav Ryhel
2026-05-12 23:29 ` sashiko-bot
2026-05-11 13:57 ` [PATCH v1 5/6] dt-bindings: phy: tegra: Document Nvidia Tegra XMM6260 PHY Svyatoslav Ryhel
2026-05-12 23:29 ` sashiko-bot
2026-05-11 13:57 ` [PATCH v1 6/6] phy: tegra: Add support for " Svyatoslav Ryhel
2026-05-12 23:29 ` sashiko-bot
2026-05-12 0:05 ` [PATCH v1 0/6] Add support for Infineon/Intel XMM6260 modem Jakub Kicinski
2026-05-12 6:05 ` 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=20260512232949.35D5AC2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=clamor95@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/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