[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200621123244.GS1551@shell.armlinux.org.uk>
Date: Sun, 21 Jun 2020 13:32:44 +0100
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Ioana Ciornei <ioana.ciornei@....com>
Cc: netdev@...r.kernel.org, davem@...emloft.net,
vladimir.oltean@....com, claudiu.manoil@....com,
alexandru.marginean@....com, michael@...le.cc, andrew@...n.ch,
f.fainelli@...il.com, olteanv@...il.com
Subject: Re: [PATCH net-next v2 0/5] net: phy: add Lynx PCS MDIO module
On Sun, Jun 21, 2020 at 02:00:00PM +0300, Ioana Ciornei wrote:
> Add support for the Lynx PCS as a separate module in drivers/net/phy/.
> The advantage of this structure is that multiple ethernet or switch
> drivers used on NXP hardware (ENETC, Felix DSA switch etc) can share the
> same implementation of PCS configuration and runtime management.
>
> The PCS is represented as an mdio_device and the callbacks exported are
> highly tied with PHYLINK and can't be used without it.
>
> The first 3 patches add some missing pieces in PHYLINK and the locked
> mdiobus write accessor. Next, the Lynx PCS MDIO module is added as a
> standalone module. The majority of the code is extracted from the Felix
> DSA driver. The last patch makes the necessary changes in the Felix
> driver in order to use the new common PCS implementation.
>
> At the moment, USXGMII (only with in-band AN and speeds up to 2500),
> SGMII, QSGMII (with and without in-band AN) and 2500Base-X (only w/o
> in-band AN) are supported by the Lynx PCS MDIO module since these were
> also supported by Felix and no functional change is intended at this
> time.
>
> Changes in v2:
> * got rid of the mdio_lynx_pcs structure and directly exported the
> functions without the need of an indirection
> * made the necessary adjustments for this in the Felix DSA driver
> * solved the broken allmodconfig build test by making the module
> tristate instead of bool
> * fixed a memory leakage in the Felix driver (the pcs structure was
> allocated twice)
>
> At this moment in time, I do not feel like a major restructuring is
> needed (ie export directly a phylink_pcs_ops from the Lynx
> module). I feel like this would limit consumers (MAC drivers) to use
> all or nothing, with no option of doing any MDIO reads/writes of their
> own (not part of the common code). Also, there is already a precedent of
> a PCS module (mdio-xpcs.c, the model of which I have followed) and
> without also changing that (which I am not comfortable doing) there is
> no point of changing this one.
Please don't write off my suggestion to use phylink_pcs_ops so lightly.
I _need_ people to move over to it, so that the phylink code can be
cleaned up - or we're going to end up with phylink gradually turning
into an unmaintainable mess. Having one way to do stuff is always
better than having multiple different backward compatible ways.
So, I /really/ want to push the phylink_pcs_ops forward, and get rid
of the ability to use the old "bolt everything into phylink_mac_ops"
approach.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists