Re: [PATCH net-next v2 0/5] net: phy: add Lynx PCS MDIO module

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

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!