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!
