[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+_ehUyAo7fMTe_P0ws_9zrcbLEWVwBXDKbezcKVkvDUUNg0rg@mail.gmail.com>
Date: Mon, 7 Apr 2025 18:46:34 +0200
From: "Christian Marangi (Ansuel)" <ansuelsmth@...il.com>
To: Sean Anderson <sean.anderson@...ux.dev>
Cc: Kory Maincent <kory.maincent@...tlin.com>, netdev@...r.kernel.org,
Andrew Lunn <andrew+netdev@...n.ch>, "David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Russell King <linux@...linux.org.uk>, linux-kernel@...r.kernel.org, upstream@...oha.com,
Heiner Kallweit <hkallweit1@...il.com>, Alexandre Belloni <alexandre.belloni@...tlin.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Christophe Leroy <christophe.leroy@...roup.eu>, Clark Wang <xiaoning.wang@....com>,
Claudiu Beznea <claudiu.beznea@...rochip.com>, Claudiu Manoil <claudiu.manoil@....com>,
Conor Dooley <conor+dt@...nel.org>, Ioana Ciornei <ioana.ciornei@....com>,
Jonathan Corbet <corbet@....net>, Joyce Ooi <joyce.ooi@...el.com>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Li Yang <leoyang.li@....com>,
Madalin Bucur <madalin.bucur@....com>, Madhavan Srinivasan <maddy@...ux.ibm.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>, Michael Ellerman <mpe@...erman.id.au>,
Michal Simek <michal.simek@....com>, Naveen N Rao <naveen@...nel.org>,
Nicholas Piggin <npiggin@...il.com>, Nicolas Ferre <nicolas.ferre@...rochip.com>,
Radhey Shyam Pandey <radhey.shyam.pandey@....com>, Rob Herring <robh+dt@...nel.org>,
Rob Herring <robh@...nel.org>, Robert Hancock <robert.hancock@...ian.com>,
Saravana Kannan <saravanak@...gle.com>, Shawn Guo <shawnguo@...nel.org>, UNGLinuxDriver@...rochip.com,
Vladimir Oltean <vladimir.oltean@....com>, Wei Fang <wei.fang@....com>, devicetree@...r.kernel.org,
imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
linux-doc@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [RFC net-next PATCH 00/13] Add PCS core support
Il giorno lun 7 apr 2025 alle ore 18:33 Sean Anderson
<sean.anderson@...ux.dev> ha scritto:
>
> On 4/7/25 12:27, Kory Maincent wrote:
> > On Thu, 3 Apr 2025 14:18:54 -0400
> > Sean Anderson <sean.anderson@...ux.dev> wrote:
> >
> >> This series adds support for creating PCSs as devices on a bus with a
> >> driver (patch 3). As initial users,
> >>
> >> - The Lynx PCS (and all of its users) is converted to this system (patch 5)
> >> - The Xilinx PCS is broken out from the AXI Ethernet driver (patches 6-8)
> >> - The Cadence MACB driver is converted to support external PCSs (namely
> >> the Xilinx PCS) (patches 9-10).
> >>
> >> The last few patches add device links for pcs-handle to improve boot times,
> >> and add compatibles for all Lynx PCSs.
> >>
> >> Care has been taken to ensure backwards-compatibility. The main source
> >> of this is that many PCS devices lack compatibles and get detected as
> >> PHYs. To address this, pcs_get_by_fwnode_compat allows drivers to edit
> >> the devicetree to add appropriate compatibles.
> >
> > I don't dive into your patch series and I don't know if you have heard about it
> > but Christian Marangi is currently working on fwnode for PCS:
> > https://lore.kernel.org/netdev/20250406221423.9723-1-ansuelsmth@gmail.com
> >
> > Maybe you should sync with him!
>
> I saw that series and made some comments. He is CC'd on this one.
>
> I think this approach has two advantages:
>
> - It completely solves the problem of the PCS being unregistered while the netdev
> (or whatever) is up
> - I have designed the interface to make it easy to convert existing
> drivers that may not be able to use the "standard" probing process
> (because they have to support other devicetree structures for
> backwards-compatibility).
>
I notice this and it's my fault for taking too long to post v2 of the PCS patch.
There was also this idea of entering the wrapper hell but I scrapped that early
as I really feel it's a workaround to the current problem present for
PCS handling.
And the real problem IMHO is that currently PCS handling is fragile and with too
many assumptions. With Daniel we also discussed backwards-compatibility.
(mainly needed for mt7621 and mt7986 (for mediatek side those are the 2
that slipped in before it was correctly complained that things were
taking a bad path)
We feel v2 permits correct support of old implementations.
The ""legacy"" implementation pose the assumption that PCS is never removed
(unless the MAC driver is removed)
That fits v2 where a MAC has to initially provide a list of PCS to
phylink instance.
With this implementation, a MAC can manually parse whatever PCS node structure
is in place and fill the PCS.
As really the "late" removal/addition of a PCS can only be supported with fwnode
implementation as dedicated PCS driver will make use of that.
I honestly hope we can skip having to enter the wrapper hell.
Anyway I also see you made REALLY GOOD documentation. Would be ideal to
collaborate for that. Anyway it's up to net maintainers on what path to follow.
Just my 2 cent on the PCS topic.
Powered by blists - more mailing lists