Re: [PATCH] net: phy: phy_ethtool_ksettings_set: Allow any supported speed

[Nikita Yushchenko <nikita.yoush@cogentembedded.com>]

>> root@vc4-033:~# ethtool tsn0
>> Settings for tsn0:
>>          Supported ports: [ MII ]
>>          Supported link modes:   2500baseT/Full
>>          Supported pause frame use: Symmetric Receive-only
>>          Supports auto-negotiation: No
> 
> Okay, the PHY can apparently only operate in fixed mode, although I
> would suggest checking that is actually the case. I suspect that may
> be a driver bug, especially as...

My contacts from Renesas say that this PHY chip is an engineering sample.

I'm not sure about the origin of "driver" for this. I did not look inside before, but now I did, and it 
is almost completely a stub. Even no init sequence. The only hw operations that this stub does are
(1) reading bit 0 of register 1.0901 and returning it as link status (phydev->link),
(2) reading bit 0 of register 1.0000 and returning it as master/slave setting (phydev->master_slave_get 
/ phydev->master_slave_state)
(3) applying phydev->master_slave_set via writing to bit 0 of register 1.0000 and then writing 0x200 to 
register 7.0200

Per standard, writing 0x200 to 7.0200 is autoneg restart, however bit 0 of 1.0000 has nothing to do with 
master/slave. So what device actually does is unclear. Just a black box that provides 2.5G Base-T1 
signalling, and software-wise can only report link and accept master-slave configuration.

Not sure if supporting this sort of black box worths kernel changes.


> it changes phydev->duplex, which is _not_ supposed to happen if
> negotiation has been disabled.

There are no writes to phydev->duplex inside the "driver".
Something in the phy core is changing it.