[PATCH net-next 00/15] net: mvpp2: fixes and improvements

[Antoine Tenart <antoine.tenart@bootlin.com>]

Hello,

This series aims to improve the Marvell PPv2 driver and to fix various
issues we encountered while testing the ports in many different
configurations. The series is based on top of Russell PPv2 phylink
rework and improvement.

I'm not sending a v2 of the previous fixes series as half the patches
are not the same and lots of development happened in between.

While this series contains fixes, it's sent to net-next as it is based
on top of Russell patches that were merged into net-next. I'm also
aiming at net-next as the series reworks critical paths of the PPv2
driver, such as the reset handling of various blocks, to let more weeks
for users to tests and for possible fixes to be sent before it lands
into a stable kernel version.

The series is divided into three parts:

- Patches 1 to 3 are cosmetic changes, sent alongside the series, as I
  saw these small issues while working on this.

- Patches 5 to 8 are fixing (or improving) individual issues that we
  found while testing PPv2.1 and PPv2.2 ports while using various
  interfaces.

  Notable fixes are we support back RGMII interfaces (on both PPv2.1 and
  PPv2.2), as their support was broken by previous patches. We also
  reworked the RXQ computation as the RXQ assignment was not checking
  the maximum number of RXQ available, and was broken for PPv2.1.

- As discussed in a previous fixes series, patches 9 to 14 rework the
  way blocks are set in reset in the PPv2 engine (plus related changes).

  There are four blocks we want to control the reset status: two MAC
  (GMAC and XLG MAC) and two PCS (MPCS and XPCS). The XLG MAC is used
  for 10G connexions and uses the MPCS or the XPCS depending on the mode
  used (10GKR / XAUI / RXAUI) and the GMAC is used for the other modes.

  The idea is to set all blocks in reset by default, and when not used,
  and to de-assert the reset only when a block is used. There are four
  cases to take in account:

  1. Boot time: all four blocks should be put in reset, as we do not
     know their initial state (configured by the firmware/bootloader).

  2. Link up: only the blocks used by a given mode should be put out of
     reset (eg. 10GKR uses the XLG MAC and the MPCS).

  3. Mode reconfiguration: some ports may support mode reconfiguration,
     and switching between the GMAC and the XLG MAC (or between the two
     PCS). All blocks should be put in reset, and only the one used
     should be put out of reset.

  4. Link down: all four blocks are put in reset.

Thanks!
Antoine

Antoine Tenart (15):
  net: mvpp2: fix a typo in the header
  net: mvpp2: update the port documentation regarding the GoP
  net: mvpp2: fix alignment of MVPP2_GMAC_CONFIG_MII_SPEED definition
  net: mvpp2: a port can be disabled even if we use the link IRQ
  net: mvpp2: reconfiguring the port interface is PPv2.2 specific
  net: mvpp2: fix validate for PPv2.1
  net: mvpp2: fix the computation of the RXQs
  net: mvpp2: some AN fields require the link to be down when updated
  net: mvpp2: always disable both MACs when disabling a port
  net: mvpp2: only update the XLG configuration when needed
  net: mvpp2: force the XLG MAC link up or down when not using in-band
  net: mvpp2: rework the XLG MAC reset handling
  net: mvpp2: reset the MACs when reconfiguring a port
  net: mvpp2: set the XPCS and MPCS in reset when not used
  net: mvpp2: set the GMAC, XLG MAC, XPCS and MPCS in reset when a port
    is down

 drivers/net/ethernet/marvell/mvpp2/mvpp2.h    |  11 +-
 .../net/ethernet/marvell/mvpp2/mvpp2_main.c   | 210 +++++++++++++-----
 2 files changed, 156 insertions(+), 65 deletions(-)

-- 
2.20.1