Re: [PATCH v1] dt-bindings: net: ethernet-phy: Add forced-master/slave properties for SPE PHYs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/6/24 09:11, Andrew Lunn wrote:
10Base-T1 often does not have autoneg, so preferred-master &
preferred-slave make non sense in this context, but i wounder if
somebody will want these later. An Ethernet switch is generally
preferred-master for example, but the client is preferred-slave.

Maybe make the property a string with supported values 'forced-master'
and 'forced-slave', leaving it open for the other two to be added
later.

My two cents, don't take it as a nack or any strong disagreement, my
experience with SPE is still limited. I agree that for SPE, it's
required that PHYs get their role assigned as early as possible,
otherwise the link can't establish. I don't see any other place but DT
to put that info, as this would be required for say, booting over the
network. This to me falls under 'HW representation', as we could do the
same with straps.

However for preferred-master / preferred-slave, wouldn't we be crossing
the blurry line of "HW description => system configuration in the DT" ?

Yes, we are somewhere near the blurry line. This is why i gave the
example of an Ethernet switch, vs a client. Again, it could be done
with straps, so following your argument, it could be considered HW
representation. But if it is set wrong, it probably does not matter,
auto-neg should still work. Except for a very small number of PHYs
whos random numbers are not random...

Having had to deal with an Ethernet PHY that requires operating in slave mode "preferably" in order to have a correct RXC duty cycle, if you force both sides of the link to "slave", auto-negotiation will fail, however thanks to auto-negotiation you can tell that there was a master/slave resolution failure. (This reminds me I need to send the patch for that PHY errata at some point).

In the case that Oleksij seems to be after, there is no auto-negotiation (is that correct?), so it seems to me that the Device Tree is coming to the rescue of an improperly strapped HW, and is used as a way to change the default HW configuration so as to have a fighting chance of having a functional link. That is not unprecedented, but it is definitively a bit blurry...
--
Florian




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux