On 10/22/24 9:38 AM, Geert Uytterhoeven wrote:
Hi Marek,
Hello Geert,
I was hoping Geert would comment on this first, but seems like maybe no.
I think, since the PHY node does have a compatible string AND the reset
is connected to the PHY, I would keep the reset property in the PHY
node. Sorry.
You are inverting the reasoning ;-) The compatible strings were added
because otherwise the PHY core can not identify the PHY when the
reset is asserted (e.g. after kexec).
... or because the PHY requires some complex sequence to bring it up, it
is not just reset.
That is your hypothetical case, but not the reason behind commit
722d55f3a9bd810f ("arm64: dts: renesas: Add compatible properties to
KSZ9031 Ethernet PHYs").
We can stick to the "reset line in unknown state" here for the sake of
this argument, it makes no difference.
If possible, I'd rather remove
the compatible strings again, as different PHYs may be mounted on
different PHY revisions, causing a headache for DTB management.
Will that ever be the case with this hardware ?
Dunno. It did happen with the Beacon boards.
Let's cross that bridge when we come to it ?
So, what would you suggest when the PHY nodes would not have compatible
strings?
I would suggest keep the PHY compatible strings, because that is the
most accurate method to describe the hardware and fulfill the PHY bring
up requirements. If the PHY changes on this hardware in some future
That issue is moot for KSZ9031.
If the PHY won't change, then we can keep the compatible strings ?
revision, we can revisit this discussion ? Maybe bootloader-applied DTOs
could work then ?
So, what would you suggest when the PHY nodes would not have compatible
strings?
I hope I already answered that question before.
[...]
