Hi Niklas,
Thanks for your series!
On Tue, Oct 22, 2024 at 8:48 PM Niklas Söderlund
<niklas.soderlund+renesas@xxxxxxxxxxxx> wrote:
> This small series wires up the Marvell 88Q2110 PHYs found on the Falcon
> Ethernet breakout board. With this applied all five PHYs are probed
> correctly.
>
> mv88q2110 e6810000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6810000.ethernet-ffffffff:07, irq=POLL)
> mv88q2110 e6820000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6820000.ethernet-ffffffff:07, irq=POLL)
> mv88q2110 e6830000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6830000.ethernet-ffffffff:07, irq=POLL)
> mv88q2110 e6840000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6840000.ethernet-ffffffff:07, irq=POLL)
> mv88q2110 e6850000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6850000.ethernet-ffffffff:07, irq=POLL)
>
> They can be auto detected with just the compatible
> "ethernet-phy-ieee802.3-c45", but to keep the style currently used I
> have added the specific compatible for the 88Q2110 as done for other
> SoCs.
If the specific compatible values are not needed, I prefer not to add
them, as DT should describe only what cannot be auto-detected[1].
Have you tried kexec and/or unbinding/rebinding the AVB driver
(the latter is probably easiest)?
> The primary issue we had with this in the past was due to an incorrect
> PHY address. After studying the schematics (v100) I found the PHYs
> address pins are wired differently on Falcon compared to other Gen4
> boards. On Falcon they are pulled-down, while on other Gen4 boards they
> are left unconnected and subjected to the PHYs internal pull-ups. This
> gives the PHY an address where the lower 3 bits of the address is
> inverted for Falcon.
This was changed in v102 of the schematics (REV0043c vs. REV0043b of
the schematics for the Ethernet sub board): See "Changed Strap pin
settings ==> PHYAD=[0,0,0], pull-down removed" on page 1, and the
various PHY configuration notes...
Moreover, this might be different in other board revisions, as the
BSP uses PHY address 1 for RAVB1, address 2 for RAVB2, and so on...
As I only had remote access to Falcon, I never knew the actual board
revision I was using.
How to handle this (yet another DTS file)?
Are non-v100 variants widespread?
[1] In theory, we could drop all SoC- and family-specific compatible
values, and just look at the Product Register. I do not suggest
going that way ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
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
