[PATCH RFC net-next 00/14] dsa/88e6xxx/phylink changes after the next merge window

["Russell King (Oracle)" <linux@armlinux.org.uk>]

Hi,

This patch series contains the minimum set of patches that I would like
to get in for the following merge window.

The first four patches are laying the groundwork for converting the
mv88e6xxx driver to use phylink PCS support. Patches 5 through 11
perform that conversion.

At that point, DSA becomes entirely phylink-legacy free, since all
drivers either set the "legacy_pre_march2020" boolean false, or use
the legacy adjust_link mechanism and thus don't implement phylink.
That then allows patches 12 and 13 which removes all setting of
legacy_pre_march2020 from DSA, since it becomes no longer relevant.

This leaves the final user of that boolean as mtk_eth_soc, which
makes use of state->speed in its mac_config() method which has
*always* been against the phylink API documentation, and has never
been guaranteed to hold a correct value in this function. Moreover,
I consider this to be broken, because it only configures the RGMII
clock rate based on state->speed when the interface changes from
something non-RGMII to RGMII. So, RGMII is probably rather broken
on the SoCs where this code path is used. I have placed a comment
in mtk_eth_soc about this, I have asked several times on lists and
Cc people about it, but I'm getting nowhere. DTS grepping seems to
indicate that there is no board that the mainline kernel supports
that would even use this code path.

The other issue with mtk_eth_soc's legacy requirement is its
implementation of mtk_mac_pcs_get_state(), and this prevents at
the moment either getting rid of the mac_pcs_get_state() method
from phylink, or marking the driver non-legacy even if we don't
care about the RGMII state->speed issue.

However, with mtk_eth_soc using phylink_pcs, we can at least kill
the old mac_an_restart function, which is what the last patch does.

I am not intending to submit this all as a single series; this is
merely being sent out as a preview for posting the first batch in
maybe three weeks time.

In the mean time, it would be great to have testing, particularly
with a range of different 88e6xxx switches (I only have a limited
subset.) Thanks.

 drivers/net/dsa/b53/b53_common.c       |    6 -
 drivers/net/dsa/mt7530.c               |    6 -
 drivers/net/dsa/mv88e6xxx/Makefile     |    3 +
 drivers/net/dsa/mv88e6xxx/chip.c       |  424 ++----------
 drivers/net/dsa/mv88e6xxx/chip.h       |   33 +-
 drivers/net/dsa/mv88e6xxx/pcs-6185.c   |  190 ++++++
 drivers/net/dsa/mv88e6xxx/pcs-6352.c   |  390 +++++++++++
 drivers/net/dsa/mv88e6xxx/pcs-639x.c   |  898 ++++++++++++++++++++++++++
 drivers/net/dsa/mv88e6xxx/port.c       |   30 -
 drivers/net/dsa/mv88e6xxx/serdes.c     | 1106 +-------------------------------
 drivers/net/dsa/mv88e6xxx/serdes.h     |  108 +---
 drivers/net/dsa/ocelot/felix.c         |    6 -
 drivers/net/dsa/qca/qca8k-8xxx.c       |    2 -
 drivers/net/dsa/sja1105/sja1105_main.c |    6 -
 drivers/net/phy/mdio_bus.c             |   24 +-
 drivers/net/phy/phylink.c              |  132 +++-
 include/linux/mdio.h                   |   26 +
 include/linux/phylink.h                |   41 +-
 include/net/dsa.h                      |    3 -
 net/dsa/port.c                         |   41 --
 20 files changed, 1742 insertions(+), 1733 deletions(-)
 create mode 100644 drivers/net/dsa/mv88e6xxx/pcs-6185.c
 create mode 100644 drivers/net/dsa/mv88e6xxx/pcs-6352.c
 create mode 100644 drivers/net/dsa/mv88e6xxx/pcs-639x.c

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!