Re: [PATCH 2/2] arm64: dts: renesas: Drop ethernet-phy-ieee802.3-c22 from PHY compatible string on all RZ boards

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Marek,

On Fri, Jul 5, 2024 at 11:50 PM Marek Vasut <marex@denx.de> wrote:
> On 7/3/24 10:24 AM, Geert Uytterhoeven wrote:
> >>> What about moving the PHYs inside an mdio subnode, and removing the
> >>> compatible properties instead? That would protect against different
> >>> board revisions using different PHYs or PHY revisions.
> >>>
> >>> According to Niklas[1], using an mdio subnode cancels the original
> >>> reason (failure to identify the PHY in reset state after unbind/rebind
> >>> or kexec) for adding the compatible values[2].
> >>
> >> My understanding is that the compatible string is necessary if the PHY
> >> needs clock/reset sequencing of any kind. Without the compatible string,
> >> it is not possible to select the correct PHY driver which would handle
> >> that sequencing according to the PHY requirements. This board here does
> >> use reset-gpio property in the PHY node (it is not visible in this diff
> >> context), so I believe a compatible string should be present here.
> >
> > With the introduction of an mdio subnode, the reset-gpios would move
> > from the PHY node to the mio subnode, cfr. commit b4944dc7b7935a02
> > ("arm64: dts: renesas: white-hawk: ethernet: Describe AVB1 and AVB2")
> > in linux-next.
>
> That's a different use case, that commit uses generic
> "ethernet-phy-ieee802.3-c45" compatible string and the PHY type is
> determined by reading out the PHY ID registers after the reset is released.
>
> This here uses specific compatible string, so the kernel can determine
> the PHY ID from the DT before the reset is released .

I am suggesting removing the specific compatible string here, too,
introducing an mdio subnode, so the kernel can read it from the PHY
ID registers after the reset is released?

> >> What would happen if this board got a revision with another PHY with
> >> different PHY reset sequencing requirements ? The MDIO node level reset
> >> handling might no longer be viable.
> >
> > True. However, please consider these two cases, both assuming
> > reset-gpios is in the MDIO node:
> >
> >    1. The PHY node has a compatible value, and a different PHY is
> >       mounted: the new PHY will not work, as the wrong PHY driver
> >       is used.
>
> What is the likelihood of such PHY exchange happening with these three
> specific boards ? I think close to none, as that would require a board
> redesign to swap in a different PHY.

I don't know about the likelihood for these boards.
It did happen before on other boards, e.g. commit a0d23b8645b2d577
("arm64: dts: renesas: beacon-renesom: Update Ethernet PHY ID").

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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