Message ID | 20200103200127.6331-1-olteanv@gmail.com |
---|---|
Headers | show |
Series | Convert Felix DSA switch to PHYLINK | expand |
From: Vladimir Oltean <olteanv@gmail.com> Date: Fri, 3 Jan 2020 22:01:18 +0200 > Unlike most other conversions, this one is not by far a trivial one, and should > be seen as "Layerscape PCS meets PHYLINK". Actually, the PCS doesn't > need a lot of hand-holding and most of our other devices 'just work' > (this one included) without any sort of operating system awareness, just > an initialization procedure done typically in the bootloader. > Our issues start when the PCS stops from "just working", and that is > where PHYLINK comes in handy. > > The PCS is not specific to the Vitesse / Microsemi / Microchip switching core > at all. Variations of this SerDes/PCS design can also be found on DPAA1 and > DPAA2 hardware. > > The main idea of the abstraction provided is that the PCS looks so much like a > PHY device, that we model it as an actual PHY device and run the generic PHY > functions on it, where appropriate. ... Series applied, please address any follow-up feedback you receive. Thank you.
On Mon, 6 Jan 2020 at 00:56, David Miller <davem@davemloft.net> wrote: > > From: Vladimir Oltean <olteanv@gmail.com> > Date: Fri, 3 Jan 2020 22:01:18 +0200 > > > Unlike most other conversions, this one is not by far a trivial one, and should > > be seen as "Layerscape PCS meets PHYLINK". Actually, the PCS doesn't > > need a lot of hand-holding and most of our other devices 'just work' > > (this one included) without any sort of operating system awareness, just > > an initialization procedure done typically in the bootloader. > > Our issues start when the PCS stops from "just working", and that is > > where PHYLINK comes in handy. > > > > The PCS is not specific to the Vitesse / Microsemi / Microchip switching core > > at all. Variations of this SerDes/PCS design can also be found on DPAA1 and > > DPAA2 hardware. > > > > The main idea of the abstraction provided is that the PCS looks so much like a > > PHY device, that we model it as an actual PHY device and run the generic PHY > > functions on it, where appropriate. > ... > > Series applied, please address any follow-up feedback you receive. > > Thank you. Thanks David, sure, ready for action. -Vladimir
From: David Miller <davem@davemloft.net> Date: Sun, 05 Jan 2020 14:56:20 -0800 (PST) > From: Vladimir Oltean <olteanv@gmail.com> > Date: Fri, 3 Jan 2020 22:01:18 +0200 > >> Unlike most other conversions, this one is not by far a trivial one, and should >> be seen as "Layerscape PCS meets PHYLINK". Actually, the PCS doesn't >> need a lot of hand-holding and most of our other devices 'just work' >> (this one included) without any sort of operating system awareness, just >> an initialization procedure done typically in the bootloader. >> Our issues start when the PCS stops from "just working", and that is >> where PHYLINK comes in handy. >> >> The PCS is not specific to the Vitesse / Microsemi / Microchip switching core >> at all. Variations of this SerDes/PCS design can also be found on DPAA1 and >> DPAA2 hardware. >> >> The main idea of the abstraction provided is that the PCS looks so much like a >> PHY device, that we model it as an actual PHY device and run the generic PHY >> functions on it, where appropriate. > ... > > Series applied, please address any follow-up feedback you receive. Actually I reverted, please fix this warning and resubmit: drivers/net/dsa/ocelot/felix.c: In function ‘felix_phylink_mac_config’: drivers/net/dsa/ocelot/felix.c:210:22: warning: unused variable ‘ocelot_port’ [-Wunused-variable] struct ocelot_port *ocelot_port = ocelot->ports[port]; ^~~~~~~~~~~ Thank you.
From: Vladimir Oltean <vladimir.oltean@nxp.com> Unlike most other conversions, this one is not by far a trivial one, and should be seen as "Layerscape PCS meets PHYLINK". Actually, the PCS doesn't need a lot of hand-holding and most of our other devices 'just work' (this one included) without any sort of operating system awareness, just an initialization procedure done typically in the bootloader. Our issues start when the PCS stops from "just working", and that is where PHYLINK comes in handy. The PCS is not specific to the Vitesse / Microsemi / Microchip switching core at all. Variations of this SerDes/PCS design can also be found on DPAA1 and DPAA2 hardware. The main idea of the abstraction provided is that the PCS looks so much like a PHY device, that we model it as an actual PHY device and run the generic PHY functions on it, where appropriate. The 4xSGMII, QSGMII and QSXGMII modes are fairly straightforward. The SerDes protocol which the driver calls 2500Base-X mode (a misnomer) is more interesting. There is a description of how it works and what can be done with it in patch 9/9 (in a comment above vsc9959_pcs_init_2500basex). In short, it is a fixed speed protocol with no auto-negotiation whatsoever. From my research of the SGMII-2500 patent [1], it has nothing to do with SGMII-2500. That one: * does not define any change to the AN base page compared to plain 10/100/1000 SGMII. This implies that the 2500 speed is not negotiable, but the other speeds are. In our case, when the SerDes is configured for this protocol it's configured for good, there's no going back to SGMII. * runs at a higher base frequency than regular SGMII. So SGMII-2500 operating at 1000 Mbps wouldn't interoperate with plain SGMII at 1000 Mbps. Strange, but ok.. * Emulates lower link speeds than 2500 by duplicating the codewords twice, then thrice, then twice again etc (2.5/25/250 times on average). The Layerscape PCS doesn't do that (it is fixed at 2500 Mbaud). But on the other hand it isn't completely compatible with Base-X either, since it doesn't do 802.3z / clause 37 auto negotiation (flow control, local/remote fault etc). It is compatible with 2500Base-X without in-band AN, and that is exactly how we decided to expose it (this is actually similar to what others do). For SGMII and USXGMII, the driver is using the PHYLINK 'managed = "in-band-status"' DTS binding to figure out whether in-band AN is expected to be enabled in the PCS or not. It is expected that the attached PHY follows suite, but there is a gap here: the PHY driver does not react to this setting, so only one of "AN on" and "AN off" works on any particular PHY, even though that PHY might support bypassing the SGMII AN process, as is the case on the VSC8514 PHY present on the LS1028A-RDB board. A separate series will be sent to propose a way to deal with that. I dropped the Ocelot PHYLINK conversion because: * I don't have VSC7514 hardware anyway * The hardware is so different in this regard that there's almost nothing to share anyway. Changes in v4: - This is mostly a resend of v3, with the only notable change that I've dropped the PHY core patches for in_band_autoneg and I'll propose them independently. v1 series: https://www.spinics.net/lists/netdev/msg613869.html RFC v2 series: https://www.spinics.net/lists/netdev/msg620128.html v3 series: https://www.spinics.net/lists/netdev/msg622060.html [0]: https://www.spinics.net/lists/netdev/msg613869.html [1]: https://patents.google.com/patent/US7356047B1/en Claudiu Manoil (1): enetc: Make MDIO accessors more generic and export to include/linux/fsl Vladimir Oltean (8): mii: Add helpers for parsing SGMII auto-negotiation net: phylink: make QSGMII a valid PHY mode for in-band AN net: phylink: add support for polling MAC PCS net: dsa: Pass pcs_poll flag from driver to PHYLINK enetc: Set MDIO_CFG_HOLD to the recommended value of 2 net: mscc: ocelot: make phy_mode a member of the common struct ocelot_port net: mscc: ocelot: export ANA, DEV and QSYS registers to include/soc/mscc net: dsa: felix: Add PCS operations for PHYLINK Documentation/networking/sfp-phylink.rst | 3 +- drivers/net/dsa/ocelot/Kconfig | 2 + drivers/net/dsa/ocelot/felix.c | 259 ++++++++- drivers/net/dsa/ocelot/felix.h | 16 +- drivers/net/dsa/ocelot/felix_vsc9959.c | 501 +++++++++++++++++- drivers/net/ethernet/freescale/enetc/Kconfig | 1 + drivers/net/ethernet/freescale/enetc/Makefile | 2 +- .../net/ethernet/freescale/enetc/enetc_hw.h | 1 + .../net/ethernet/freescale/enetc/enetc_mdio.c | 120 ++--- .../net/ethernet/freescale/enetc/enetc_mdio.h | 12 - .../ethernet/freescale/enetc/enetc_pci_mdio.c | 43 +- .../net/ethernet/freescale/enetc/enetc_pf.c | 47 ++ .../net/ethernet/freescale/enetc/enetc_pf.h | 4 - drivers/net/ethernet/mscc/ocelot.c | 7 +- drivers/net/ethernet/mscc/ocelot.h | 7 +- drivers/net/ethernet/mscc/ocelot_board.c | 4 +- drivers/net/phy/phylink.c | 4 +- include/linux/fsl/enetc_mdio.h | 55 ++ include/linux/mii.h | 50 ++ include/linux/phylink.h | 2 + include/net/dsa.h | 5 + include/soc/mscc/ocelot.h | 2 + .../soc}/mscc/ocelot_ana.h | 0 .../soc}/mscc/ocelot_dev.h | 0 .../soc}/mscc/ocelot_qsys.h | 0 include/uapi/linux/mii.h | 12 + net/dsa/port.c | 1 + 27 files changed, 1030 insertions(+), 130 deletions(-) delete mode 100644 drivers/net/ethernet/freescale/enetc/enetc_mdio.h create mode 100644 include/linux/fsl/enetc_mdio.h rename {drivers/net/ethernet => include/soc}/mscc/ocelot_ana.h (100%) rename {drivers/net/ethernet => include/soc}/mscc/ocelot_dev.h (100%) rename {drivers/net/ethernet => include/soc}/mscc/ocelot_qsys.h (100%)