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!