[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZuFAAVBGw7ApUk6S@pengutronix.de>
Date: Wed, 11 Sep 2024 09:00:17 +0200
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Rob Herring <robh@...nel.org>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Florian Fainelli <f.fainelli@...il.com>, kernel@...gutronix.de,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
Russell King <linux@...linux.org.uk>, devicetree@...r.kernel.org
Subject: Re: [PATCH net-next v2 1/2] dt-bindings: net: ethernet-phy: Add
master-slave role property for SPE PHYs
On Tue, Sep 10, 2024 at 11:54:04AM -0500, Rob Herring wrote:
> On Mon, Sep 9, 2024 at 12:00 PM Andrew Lunn <andrew@...n.ch> wrote:
....
> > The 2022 revision of 802.3 still has master/slave when describing the
> > registers, but it does have Annex K as described above saying "leader"
> > and "follower" are optional substitutions.
> >
> > The Linux code has not changed, and the uAPI has not changed. It seems
> > like the best compromise would be to allow both 'force-master' and
> > 'force-leader', as well as 'force-slave' and 'force-follower', and a
> > reference to 802.3 Annex K.
>
> It seems silly to maintain both forever. I'd rather have one or the
> other than both.
I'll accept what ever will be decided. Even if we will decide to use
words 'leader' and 'follower' for the properties, we still need to
document that they correspond to 'master' and 'slave' in the IEEE
specification and in the kernel UAPI.
I can imagine a mdi-link-clock-role = 'leader' or 'follower'
> > As to you comment about it being unclear what it means i would suggest
> > a reference to 802.3 section 1.4.389:
> >
> > 1.4.389 master Physical Layer device (PHY): Within IEEE 802.3, in a
> > 100BASE-T2, 1000BASE-T, 10BASE-T1L, 100BASE-T1, 1000BASE-T1, or any
> > MultiGBASE-T link containing a pair of PHYs, the PHY that uses an
> > external clock for generating its clock signals to determine the
> > timing of transmitter and receiver operations. It also uses the
> > master transmit scrambler generator polynomial for side-stream
> > scrambling. Master and slave PHY status is determined during the
> > Auto-Negotiation process that takes place prior to establishing the
> > transmission link, or in the case of a PHY where Auto-Negotiation is
> > optional and not used, master and slave PHY status
>
> phy-status? Shrug.
In my understanding, the 'status' is result not actual configuration
request.
> Another thought. Is it possible that h/w strapping disables auto-neg,
> but you actually want to override that and force auto-neg?
Yes. If I would need it, I would recommend to have a different override
property, something like: autoneg-default = 'on' or 'off'
Regards,
Oleksij
--
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 |
Powered by blists - more mailing lists