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

[Marek Vasut]

On 7/3/24 10:24 AM, Geert Uytterhoeven wrote:
> Hi Marek,

Hi,

[...]

>>> 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 .

> Niklas: commit 54bf0c27380b95a2 ("arm64: dts: renesas: r8a779g0: Use
> MDIO node for all AVB devices") did keep the reset-gpios property in
> the PHY node. I guess it should be moved one level up?
> 
> Does the rtl82xx PHY have special reset sequencing requirements?

Aside from reset timing, which does not seem to be in use here, not that 
I am aware of.

>> 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.

>    2. The PHY node does not have a compatible value, and a different
>       PHY is mounted:
>         a. The new PHY does not need specific reset sequencing,
>            and the existing reset-gpios is fine: the new PHY will just
>            work, as it is auto-detected.

Or maybe, it will work by sheer chance, the reset timing would be off 
for the new PHY, but nobody will notice until much later. At least with 
the specific compatible string, such a PHY exchange would be detected 
outright.

>         b. The new PHY does need specific reset sequencing: the
>            new PHY will not work.
> 
> Which case is preferable? Case 1 or 2?

I think 1 because that is the well defined option which always works or 
always fails.