[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGb2v67cKrQygew2CVaq5GCGvzcpkSdU_12Gjq9KR7tFFBow0Q@mail.gmail.com>
Date: Wed, 13 Aug 2025 23:51:18 +0800
From: Chen-Yu Tsai <wens@...nel.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Jernej Skrabec <jernej@...nel.org>, Samuel Holland <samuel@...lland.org>, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org,
Andre Przywara <andre.przywara@....com>
Subject: Re: [PATCH net-next v2 06/10] arm64: dts: allwinner: a527: cubie-a5e:
Add ethernet PHY reset setting
On Wed, Aug 13, 2025 at 11:12 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:
>
> On Wed, Aug 13, 2025 at 10:55:36PM +0800, Chen-Yu Tsai wrote:
> > diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts b/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
> > index 70d439bc845c..d4cee2222104 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
> > @@ -94,6 +94,9 @@ &mdio0 {
> > ext_rgmii_phy: ethernet-phy@1 {
> > compatible = "ethernet-phy-ieee802.3-c22";
> > reg = <1>;
> > + reset-gpios = <&pio 7 8 GPIO_ACTIVE_LOW>; /* PH8 */
> > + reset-assert-us = <10000>;
> > + reset-deassert-us = <150000>;
>
> Please verify that kexec works with this, as if the calling kernel
> places the PHY in reset and then kexec's, and the reset remains
> asserted, the PHY will not be detected.
I found this to be a bit confusing to be honest.
If I put the reset description in the PHY (where I think it belongs),
then it wouldn't work if the reset isn't by default deasserted (through
some pull-up). This would be similar to the kexec scenario.
Whereas if I put the reset under the MDIO bus, then the core would
deassert the reset before scanning the bus.
It's confusing to me because the code already goes through the MDIO bus
device tree node and *knows* that there are PHYs under it, and that the
PHYs might have a reset. And it can even handle them _after_ the initial
bus scan.
Describing the PHY reset as a bus reset IMHO isn't correct.
ChenYu
Powered by blists - more mailing lists