On 7/2/24 10:38 AM, Geert Uytterhoeven wrote:
Hi Marek,
Hi,
On Sun, Jun 30, 2024 at 5:47 AM Marek Vasut <marex@xxxxxxx> wrote:
The rtl82xx DT bindings do not require ethernet-phy-ieee802.3-c22
as the fallback compatible string. There are fewer users of the
Realtek PHY compatible string with fallback compatible string than
there are users without fallback compatible string, so drop the
fallback compatible string from the few remaining users:
$ git grep -ho ethernet-phy-id001c....... | sort | uniq -c
1 ethernet-phy-id001c.c816",
2 ethernet-phy-id001c.c915",
2 ethernet-phy-id001c.c915";
5 ethernet-phy-id001c.c916",
13 ethernet-phy-id001c.c916";
Reported-by: kernel test robot <lkp@xxxxxxxxx>
Closes: https://lore.kernel.org/oe-kbuild-all/202406290316.YvZdvLxu-lkp@xxxxxxxxx/
Signed-off-by: Marek Vasut <marex@xxxxxxx>
Thanks for your patch!
Note: this closes only part of the report
In that case you should use a Link: instead of a Closes: tag?
But which patch would be the one that Closes that report then ?
--- a/arch/arm64/boot/dts/renesas/cat875.dtsi
+++ b/arch/arm64/boot/dts/renesas/cat875.dtsi
@@ -22,8 +22,7 @@ &avb {
status = "okay";
phy0: ethernet-phy@0 {
- compatible = "ethernet-phy-id001c.c915",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id001c.c915";
reg = <0>;
interrupt-parent = <&gpio2>;
interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
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.
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.
