diff options
author | David S. Miller <davem@davemloft.net> | 2019-03-01 23:23:35 -0800 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2019-03-01 23:23:35 -0800 |
commit | 04c2632a6c7487c27c91306ad2eba35fe0a59069 (patch) | |
tree | 19a5498ec013bda874764171463a8b0d51ffd083 /net | |
parent | 57d37aea0e2e0a8330ebf4f41150a641a8ccd869 (diff) | |
parent | 1f69afce382f2858c825f027ed5afa97ec532f3e (diff) | |
download | linux-04c2632a6c7487c27c91306ad2eba35fe0a59069.tar.bz2 |
Merge branch 'net-mvpp2-fixes-and-improvements'
Antoine Tenart says:
====================
net: mvpp2: fixes and improvements
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 15 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.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions