[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHCN7x+aGm50mfoDkPDGHnm4zTyNSf8VEPWKHDKx=u+0y4VJPg@mail.gmail.com>
Date: Fri, 6 Jan 2023 08:49:20 -0600
From: Adam Ford <aford173@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: linux-renesas-soc@...r.kernel.org, aford@...conembedded.com,
Magnus Damm <magnus.damm@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/4] Revert "arm64: dts: renesas: Add compatible
properties to AR8031 Ethernet PHYs"
On Fri, Jan 6, 2023 at 8:45 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Adam,
>
> On Fri, Jan 6, 2023 at 3:35 PM Adam Ford <aford173@...il.com> wrote:
> > On Fri, Jan 6, 2023 at 8:28 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > On Wed, Jan 4, 2023 at 3:12 PM Adam Ford <aford173@...il.com> wrote:
> > > > This reverts commit 18a2427146bf8a3da8fc7825051d6aadb9c2d8fb.
> > > >
> > > > Due to the part shortage, the AR8031 PHY was replaced with a
> > > > Micrel KSZ9131. Hard-coding the ID of the PHY makes this new
> > > > PHY non-operational. Since previous hardware had shipped,
> > > > it's not as simple as just replacing the ID number as it would
> > > > break the older hardware. Since the generic mode can correctly
> > > > identify both versions of hardware, it seems safer to revert
> > > > this patch.
> > > >
> > > > Signed-off-by: Adam Ford <aford173@...il.com>
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
> > > > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
> > > > @@ -59,8 +59,6 @@ &avb {
> > > > status = "okay";
> > > >
> > > > phy0: ethernet-phy@0 {
> > > > - compatible = "ethernet-phy-id004d.d074",
> > > > - "ethernet-phy-ieee802.3-c22";
> > > > reg = <0>;
> > > > interrupt-parent = <&gpio2>;
> > > > interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> > >
> > > The next line:
> > >
> > > reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
> > >
> > > Unfortunately, removing the compatible value will cause regressions
> > > for kexec/kdump and for Ethernet driver unbind, as the PHY reset will
> > > be asserted before starting the new kernel, or on driver unbind.
> > > Due to a deficiency in the Ethernet PHY subsystem, the PHY will be
> > > probed while the reset is still asserted, and thus fail probing[1].
> >
> > FWIW, the bootloader brings the device out of reset. Would it be
>
> The bootloader is not involved when using kexec/kdump, or when
> unbinding the Ethernet driver.
>
> > sufficient to keep "ethernet-phy-ieee802.3-c22" and drop the
> > hard-coded ID?
>
> I am afraid not, as that still requires actual probing to determine
> the PHY ID.
OK. I'll try to find out how many of the older versions of the board
shipped. I don't really want to maintain two device trees for a small
population of boards. Even those customers with early hardware won't
be getting the same versions going forward and Qualcomm/Atheros told
us it's an EOL part and cancelled our orders. If there are no
objections, I might just change the ID to the new PHY. The customers
who received the older hardware should have already been notified of
the hardware change and the fact they won't get any more with that
PHY.
adam
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
Powered by blists - more mailing lists