On Fri, Sep 06, 2024 at 05:11:54PM +0200, Andrew Lunn wrote: > On Fri, Sep 06, 2024 at 04:49:05PM +0200, Oleksij Rempel wrote: > > Add two new properties, `forced-master` and `forced-slave`, to the > > ethernet-phy binding. These properties are intended for Single Pair > > Ethernet (1000/100/10Base-T1) PHYs, where each PHY and product may have > > a predefined link role (master or slave). Typically, these roles are set > > by hardware strap pins, but in some cases, device tree configuration is > > necessary. > > > > Signed-off-by: Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> > > --- > > .../devicetree/bindings/net/ethernet-phy.yaml | 22 +++++++++++++++++++ > > 1 file changed, 22 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml > > index d9b62741a2259..af7a1eb6ceff6 100644 > > --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml > > +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml > > @@ -158,6 +158,28 @@ properties: > > Mark the corresponding energy efficient ethernet mode as > > broken and request the ethernet to stop advertising it. > > > > + forced-master: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + If set, forces the PHY to operate as a master. This is used in Single Pair > > + Ethernet (1000/100/10Base-T1) where each PHY and product has a predefined > > + link role (master or slave). This property is board-specific, as the role > > + is usually configured by strap pins but can be set through the device tree > > + if needed. > > + This property is mutually exclusive with 'forced-slave'; only one of them > > + should be used. > > DT reviewers tend to complain about such mutually exclusive > properties. Yes, at this point i was uncertain. > What you are effectively adding is support for the ethtool: > > ethtool -s [master-slave preferred-master|preferred-slave|forced-master|forced-slave] ack > 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. Good point. > 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. > > I've not seen the implementation yet, but i don't think there is much > driver specific here. We already have phydev->master_slave_set, it > just needs to be set from this property. Can it be done in phylib core > somewhere? Yes, this is the idea. -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
