Stop ~100 lines of CMD 1802 returned error -19 on every R4 Pro boot

[meehien]

The four internal 2.5G PHYs on the MxL86252C are GPY cores reachable only
through the switch firmware's MDIO relay. mxl-gpy writes optional VEND1
vendor registers during config_init (LED config, temperature/WOL mailbox)
and tolerates failures. The R4 Pro's 1.0.70 firmware doesn't implement them
and rejects each write with -ENODEV, and the relay logs every one:

mxl862xx mdio-bus:10: CMD 1802 returned error -19

~100 lines per cold boot on a board where all four ports come up and pass
traffic normally. These are PHY-layer accesses whose success is the PHY
driver's business, not the switch's, so route both relay directions through
the existing quiet path (already used for the firmware-version probe).
Genuine switch-command failures are still logged.

[frank-w]

These errors are triggered by the as21 phy driver which is a workaround. It writes to non existent phy-id. But i had not figured out why mxl internal mdio reacts to the as21 phy which are on another mdio bus.

You can disable the as21 driver and see the errors are gone. Sdk driver also just silece these errors,which imho is not the right way.

[meehien]

let me investigate this a bit more then.

[frank-w]

https://github.com/frank-w/BPI-Router-Linux/blob/7.1-main/drivers/net/phy/as21xx_1.9.2/as21xxx.c#L472

this is the workaround in 1.9.2 driver. afair without it register-writes got not executed (but i see it is called also for C45 read operations, and aeon_mdio_{read,write} use the same line without calling this function...maybe some can be dropped to reduce the flooding)...mtk told about a possible way to write to readonly phy register instead of non-existing device, but i have not found out such register in the as21 phy so have tried it yet.

[meehien]

ok. i think I got this figured out. i'll do another PR tomorrow instead of this.