Hi Andrew,
Andrew Lunn wrote:
What do you get when you read registers 2 and 3 of the SERDES? Is
there an ID in them?
If the mdio bus is scanned, and there is an ID, phylib will try to
probe a PHY driver on the SERDES.
I read them on the board. Registers 0 to 3 at address 9 all read
0x0000, while addresses with nothing on them like 7, 20 and 30 read
0xffff. Something does answer at address 9 though, since registers 22
and 27 there hold the values the driver writes.
So there is no ID, and no PHY driver would match ID 0. But phylib only
treats an ID with all of its low 29 bits set as no device, so a bus
scan would still register a PHY device at address 9. On this board the
MDIO node lists its PHYs, so of_mdiobus_register() does not scan and no
device shows up at address 9.
I would suggest adding a probe, and validate phydev->mdio.addr is not
31. ENODEV, or EINVAL, to indicate the setup is invalid.
Done in my tree, the probe returns -EINVAL for address 31.
It would be nice to reverse engineer what these bits do. And then add
proper LED controls. However, that can be later.
OK, I will look at the LEDs later.
This says it is an RGMII PHY. Why does it have a SERDES? That suggests
SGMII?
We need to understand this, because if it is an RGMII PHY, we need to
address the RGMII delays, which that page says it can controller.
That part I still have to find out. My driver has always told phylib
gmii and the WAN port runs at 1 Gbs, but I have not worked out yet
what the link between the SoC and the ZX5201 really is. SerDes was just
the name I gave the registers at the second address, and there is no
public documentation for them. I will find out what the interface is,
and how the delays are set if it is RGMII, before I send the networking
patches again.
Best regards,
Navid