OSDN Git Service

net: enetc: apply the MDIO workaround for XDP_REDIRECT too
authorVladimir Oltean <vladimir.oltean@nxp.com>
Fri, 16 Apr 2021 21:22:25 +0000 (00:22 +0300)
committerDavid S. Miller <davem@davemloft.net>
Sat, 17 Apr 2021 00:08:40 +0000 (17:08 -0700)
commit24e393097171719e3a64abb8f4cc7bf8fbce2ac4
tree5b737b64795e17633657e2e78561048d4c1bd7b1
parent92ff9a6e578dc32950567efaf987328c32fefdc6
net: enetc: apply the MDIO workaround for XDP_REDIRECT too

Described in fd5736bf9f23 ("enetc: Workaround for MDIO register access
issue") is a workaround for a hardware bug that requires a register
access of the MDIO controller to never happen concurrently with a
register access of a port PF. To avoid that, a mutual exclusion scheme
with rwlocks was implemented - the port PF accessors are the 'read'
side, and the MDIO accessors are the 'write' side.

When we do XDP_REDIRECT between two ENETC interfaces, all is fine
because the MDIO lock is already taken from the NAPI poll loop.

But when the ingress interface is not ENETC, just the egress is, the
MDIO lock is not taken, so we might access the port PF registers
concurrently with MDIO, which will make the link flap due to wrong
values returned from the PHY.

To avoid this, let's just slap an enetc_lock_mdio/enetc_unlock_mdio at
the beginning and ending of enetc_xdp_xmit. The fact that the MDIO lock
is designed as a rwlock is important here, because the read side is
reentrant (that is one of the main reasons why we chose it). Usually,
the way we benefit of its reentrancy is by running the data path
concurrently on both CPUs, but in this case, we benefit from the
reentrancy by taking the lock even when the lock is already taken
(and that's the situation where ENETC is both the ingress and the egress
interface for XDP_REDIRECT, which was fine before and still is fine now).

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/ethernet/freescale/enetc/enetc.c