Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Joy Zou" <joy.zou@nxp.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org,
	Frank.Li@kernel.org, robh@kernel.org, imx@lists.linux.dev
Subject: Re: [PATCH 4/5] arm64: dts: imx91-11x11-evk: add reset gpios for ethernet PHYs
Date: Tue, 19 May 2026 12:05:11 +0000	[thread overview]
Message-ID: <20260519120511.C59D6C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260519-b4-imx91-qsb-opt-v1-4-9b416d2dc224@nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing `compatible` string with PHY ID in ethernet-phy nodes causes silent probe failure when using reset-gpios.
--

commit 3c4c46607dcfd2582ce8a02581310d0901a9d667
Author: Joy Zou <joy.zou@nxp.com>

arm64: dts: imx91-11x11-evk: add reset gpios for ethernet PHYs

This commit adds reset GPIO properties for the ethernet PHYs using
an I2C GPIO expander. This allows the PHYs on both the EQOS and FEC
interfaces to be reset during initialization.

> diff --git a/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
> --- a/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
[ ... ]
> @@ -198,6 +198,9 @@ mdio {
>  
>  		ethphy1: ethernet-phy@1 {
>  			reg = <1>;
> +			reset-gpios = <&pcal6524 15 GPIO_ACTIVE_LOW>;

Will this cause a silent probe failure if the PHY is held in reset at boot?

Because there is no explicit compatible string with the PHY ID (for example,
compatible = "ethernet-phy-idXXXX.YYYY"), the MDIO core must auto-detect
the PHY by reading its ID registers over the MDIO bus.

If the PHY is currently held in reset, the MDIO read will fail and return
0xFFFF. This causes get_phy_device() to return -ENODEV before the device
is created.

Since the device instantiation is skipped, the reset-gpios are never requested
or deasserted, and the I2C expander probe deferral mechanism is bypassed,
leaving the ethernet interface permanently disabled.

Should these PHY nodes explicitly include the PHY ID in the compatible property
to bypass the hardware ID read, allowing the kernel to wait for the I2C
expander to be ready and properly deassert the reset?

> +			reset-assert-us = <10000>;
> +			reset-deassert-us = <80000>;
>  			realtek,clkout-disable;
>  		};
>  	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-b4-imx91-qsb-opt-v1-0-9b416d2dc224@nxp.com?part=4

  reply	other threads:[~2026-05-19 12:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19 11:15 [PATCH 0/5] arm64: dts: imx91-11x11-evk/imx91-9x9-qsb: misc cleanups and improvements Joy Zou
2026-05-19 11:15 ` [PATCH 1/5] arm64: dts: imx91-9x9-qsb: remove unused property clock-frequency from mdio node Joy Zou
2026-05-19 11:23   ` sashiko-bot
2026-05-19 11:15 ` [PATCH 2/5] arm64: dts: imx91-9x9-qsb: add pinctrl for wdog3 reset Joy Zou
2026-05-19 11:15 ` [PATCH 3/5] arm64: dts: imx91-11x11-evk: " Joy Zou
2026-05-19 11:15 ` [PATCH 4/5] arm64: dts: imx91-11x11-evk: add reset gpios for ethernet PHYs Joy Zou
2026-05-19 12:05   ` sashiko-bot [this message]
2026-05-19 11:15 ` [PATCH 5/5] arm64: dts: imx91-9x9-qsb: " Joy Zou

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=20260519120511.C59D6C2BCB3@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=joy.zou@nxp.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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