Message-ID: <CA+_ehUzeMBFrDEb7Abn3UO3S7VVjMiKc+2o=p5RGjPDkfLPVtQ@mail.gmail.com>
Date: Mon, 7 Apr 2025 19:21:38 +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 19:00 Sean Anderson
<sean.anderson@...ux.dev> ha scritto:
>
> On 4/7/25 12:46, Christian Marangi (Ansuel) wrote:
> > 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.
>
> It's no workaround. The fundamental problem is that drivers can become
> unbound at any time, and we cannot make consumers drop their references.
> Every subsystem must deal with this reality, or suffer from
> user-after-free bugs. See [1-3] for discussion of this problem in
> relation to PCSs and PHYs, and [4] for more discussion of my approach.
>
> [1] https://lore.kernel.org/netdev/YV7Kp2k8VvN7J0fY@shell.armlinux.org.uk/
> [2] https://lore.kernel.org/netdev/20220816163701.1578850-1-sean.anderson@seco.com/
> [3] https://lore.kernel.org/netdev/9747f8ef-66b3-0870-cbc0-c1783896b30d@seco.com/
> [3] https://lpc.events/event/17/contributions/1627/
>
> > 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.
>
> And what happens when the driver is unbound from the device and suddenly
> a PCS on that list is free'd memory but is in active use by a netdev?
>

driver bug for not correctly implementing the removal task.

The approach is remove as provider and call phylink removal phase
under rtnl lock.
We tested this with unbind, that is actually the main problem we are
trying to address
and works correctly.

> > 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 agree that a "cells" approach would require this, but
>
> - There are no in-tree examples of where this is necessary
> - I think this would be easy to add when necessary
>

There are no in-tree cause only now we are starting to support
complex configuration with multiple PCS placed outside the MAC.

I feel it's better to define a standard API for them now before
we permit even more MAC driver to implement custom property
and have to address tons of workaround for compatibility.

> > I honestly hope we can skip having to enter the wrapper hell.
>
> Unfortunately, this is required by the kernel driver model :l
>
> > Anyway I also see you made REALLY GOOD documentation.
>
> Thanks. One of my peeves is subsystems that have zero docs...
>
> > 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.
>
> --Sean

Powered by blists - more mailing lists