Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Svyatoslav Ryhel" <clamor95@gmail.com>
Cc: conor+dt@kernel.org, krzk+dt@kernel.org, robh@kernel.org,
	devicetree@vger.kernel.org, neil.armstrong@linaro.org,
	vkoul@kernel.org, linux-phy@lists.infradead.org,
	olteanv@gmail.com
Subject: Re: [PATCH v1 6/6] phy: tegra: Add support for Nvidia Tegra XMM6260 PHY
Date: Tue, 12 May 2026 23:29:52 +0000	[thread overview]
Message-ID: <20260512232952.D4FDEC2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260511135703.62470-7-clamor95@gmail.com>

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [Critical] Incorrect error checking of `of_parse_phandle()` leads to arbitrary device matching and memory corruption.
- [Critical] Type confusion and NULL pointer dereference due to illegal access of an external device's driver data.
- [High] Permanent memory and reference count leak of the USB platform device.
- [Medium] Improper usage of `dev_err_probe()` inside runtime execution paths.
- [Medium] Missing Kconfig dependency on `CONFIG_USB_PHY`.
--

commit c599fd7b5a962e5696a6eb64dff41cd0427d8dde
Author: Svyatoslav Ryhel <clamor95@gmail.com>

phy: tegra: Add support for Nvidia Tegra XMM6260 PHY

Nvidia Tegra XMM6260 PHY is a hardware configuration used in Tegra SoCs
to provide proper interaction between the application processor and the
modem, as well as control over one of the SoC's USB lines for the modem.

> diff --git a/drivers/phy/tegra/Kconfig b/drivers/phy/tegra/Kconfig
> index 342fb736da4b1..41b5ce460f37c 100644
> --- a/drivers/phy/tegra/Kconfig
> +++ b/drivers/phy/tegra/Kconfig
> @@ -18,3 +18,15 @@ config PHY_TEGRA194_P2U
>  	help
>  	  Enable this to support the P2U (PIPE to UPHY) that is part of Tegra 19x
>  	  and 234 SOCs.
> +
> +config PHY_TEGRA_XMM6260
> +	tristate "NVIDIA Tegra XMM6260 PHY driver"
> +	depends on ARCH_TEGRA && USB_NET_XMM6260 && USB_SUPPORT
> +	select GENERIC_PHY

This driver relies on USB PHY APIs like devm_usb_get_phy_by_phandle(), but
doesn't seem to depend on USB_PHY. Could this cause silent probe failures if
CONFIG_USB_PHY is disabled and the stub functions are used?

[ ... ]

> diff --git a/drivers/phy/tegra/phy-tegra-xmm6260.c b/drivers/phy/tegra/phy-tegra-xmm6260.c
> new file mode 100644
> index 0000000000000..7511de1333aaf
> --- /dev/null
> +++ b/drivers/phy/tegra/phy-tegra-xmm6260.c
[ ... ]
> +struct tegra_usb_device {
> +	struct ci_hdrc_platform_data data;
> +	struct platform_device *dev;
> +};
[ ... ]
> +static int tegra_xmm6260_phy_power_on(struct phy *phy)
> +{
> +	struct tegra_xmm6260_phy *mphy = phy_get_drvdata(phy);
> +	struct tegra_usb_device *usb = platform_get_drvdata(mphy->usb_dev);

Does this rely on the exact memory layout of an external driver's private
structure? The tegra_usb_device struct is defined locally here.

Also, if the external driver hasn't probed yet, platform_get_drvdata()
returns NULL, which could lead to a NULL pointer dereference later when
accessing usb->dev.

> +	int ret;
> +
> +	gpiod_set_value_cansleep(mphy->enable_gpio, 1);
> +
> +	ret = usb_phy_init(mphy->usb_phy);
> +	if (ret) {
> +		gpiod_set_value_cansleep(mphy->enable_gpio, 0);
> +		return dev_err_probe(mphy->dev, ret,
> +				     "failed to init USB PHY\n");
> +	}

Is it safe to call dev_err_probe() outside of a probe function? This is a
runtime PHY operation callback, and using dev_err_probe() here might pollute
the deferred probe lists if the error code happens to match -EPROBE_DEFER.

[ ... ]
> +static int tegra_xmm6260_phy_probe(struct platform_device *pdev)
> +{
[ ... ]
> +	usb_node = of_parse_phandle(dev->of_node, "nvidia,usb-bus", 0);
> +	if (IS_ERR(usb_node))
> +		return dev_err_probe(dev, PTR_ERR(usb_node),
> +				     "failed to parse modem USB bus\n");

Should this check be if (!usb_node) instead? of_parse_phandle() returns NULL
when a property is missing, not an ERR_PTR.

If usb_node is NULL, this check is bypassed and of_find_device_by_node(NULL)
will be called below, which matches the very first platform device in the
system lacking a device tree node.

> +
> +	mphy->usb_dev = of_find_device_by_node(usb_node);
> +	of_node_put(usb_node);
> +	if (!mphy->usb_dev)
> +		return dev_err_probe(dev, -ENODEV,
> +				     "failed to get modem USB bus\n");

Does this leak the reference to the platform_device returned by
of_find_device_by_node()? It increments the reference count via
get_device(), but there doesn't seem to be a corresponding put_device() in
the error paths below or in a remove callback.

> +
> +	mphy->usb_phy = devm_usb_get_phy_by_phandle(dev, "nvidia,usb-bus", 1);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511135703.62470-1-clamor95@gmail.com?part=6

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  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
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 [this message]
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=20260512232952.D4FDEC2BCB0@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