linux-stable.git/drivers/net/dsa/microchip, branch v6.2.8

net: dsa: microchip: fix RGMII delay configuration on KSZ8765/KSZ8794/KSZ8795

2023-03-22T12:37:53+00:00

[ Upstream commit 5ae06327a3a5bad4ee246d81df203b1b00a7b390 ]

The blamed commit has replaced a ksz_write8() call to address
REG_PORT_5_CTRL_6 (0x56) with a ksz_set_xmii() -> ksz_pwrite8() call to
regs[P_XMII_CTRL_1], which is also defined as 0x56 for ksz8795_regs[].

The trouble is that, when compared to ksz_write8(), ksz_pwrite8() also
adjusts the register offset with the port base address. So in reality,
ksz_pwrite8(offset=0x56) accesses register 0x56 + 0x50 = 0xa6, which in
this switch appears to be unmapped, and the RGMII delay configuration on
the CPU port does nothing.

So if the switch wasn't fine with the RGMII delay configuration done
through pin strapping and relied on Linux to apply a different one in
order to pass traffic, this is now broken.

Using the offset translation logic imposed by ksz_pwrite8(), the correct
value for regs[P_XMII_CTRL_1] should have been 0x6 on ksz8795_regs[], in
order to really end up accessing register 0x56.

Static code analysis shows that, despite there being multiple other
accesses to regs[P_XMII_CTRL_1] in this driver, the only code path that
is applicable to ksz8795_regs[] and ksz8_dev_ops is ksz_set_xmii().
Therefore, the problem is isolated to RGMII delays.

In its current form, ksz8795_regs[] contains the same value for
P_XMII_CTRL_0 and for P_XMII_CTRL_1, and this raises valid suspicions
that writes made by the driver to regs[P_XMII_CTRL_0] might overwrite
writes made to regs[P_XMII_CTRL_1] or vice versa.

Again, static analysis shows that the only accesses to P_XMII_CTRL_0
from the driver are made from code paths which are not reachable with
ksz8_dev_ops. So the accesses made by ksz_set_xmii() are safe for this
switch family.

[ vladimiroltean: rewrote commit message ]

Fixes: c476bede4b0f ("net: dsa: microchip: ksz8795: use common xmii function")
Signed-off-by: Marek Vasut 
Signed-off-by: Vladimir Oltean 
Acked-by: Arun Ramadoss 
Reviewed-by: Florian Fainelli 
Link: https://lore.kernel.org/r/20230315231916.2998480-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: dsa: microchip: fix probe of I2C-connected KSZ8563

2023-01-24T05:40:54+00:00

Starting with commit eee16b147121 ("net: dsa: microchip: perform the
compatibility check for dev probed"), the KSZ switch driver now bails
out if it thinks the DT compatible doesn't match the actual chip ID
read back from the hardware:

  ksz9477-switch 1-005f: Device tree specifies chip KSZ9893 but found
  KSZ8563, please fix it!

For the KSZ8563, which used ksz_switch_chips[KSZ9893], this was fine
at first, because it indeed shares the same chip id as the KSZ9893.

Commit b44908095612 ("net: dsa: microchip: add separate struct
ksz_chip_data for KSZ8563 chip") started differentiating KSZ9893
compatible chips by consulting the 0x1F register. The resulting breakage
was fixed for the SPI driver in the same commit by introducing the
appropriate ksz_switch_chips[KSZ8563], but not for the I2C driver.

Fix this for I2C-connected KSZ8563 now to get it probing again.

Fixes: b44908095612 ("net: dsa: microchip: add separate struct ksz_chip_data for KSZ8563 chip").
Reviewed-by: Andrew Lunn 
Signed-off-by: Ahmad Fatoum 
Acked-by: Arun Ramadoss 
Reviewed-by: Florian Fainelli 
Link: https://lore.kernel.org/r/20230120110933.1151054-1-a.fatoum@pengutronix.de
Signed-off-by: Jakub Kicinski

net: dsa: microchip: ksz9477: port map correction in ALU table entry register

2023-01-19T17:28:31+00:00

ALU table entry 2 register in KSZ9477 have bit positions reserved for
forwarding port map. This field is referred in ksz9477_fdb_del() for
clearing forward port map and alu table.

But current fdb_del refer ALU table entry 3 register for accessing forward
port map. Update ksz9477_fdb_del() to get forward port map from correct
alu table entry register.

With this bug, issue can be observed while deleting static MAC entries.
Delete any specific MAC entry using "bridge fdb del" command. This should
clear all the specified MAC entries. But it is observed that entries with
self static alone are retained.

Tested on LAN9370 EVB since ksz9477_fdb_del() is used common across
LAN937x and KSZ series.

Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477")
Signed-off-by: Rakesh Sankaranarayanan 
Reviewed-by: Vladimir Oltean 
Link: https://lore.kernel.org/r/20230118174735.702377-1-rakesh.sankaranarayanan@microchip.com
Signed-off-by: Jakub Kicinski

net: dsa: microchip: remove IRQF_TRIGGER_FALLING in request_threaded_irq

2022-12-20T01:18:48+00:00

KSZ swithes used interrupts for detecting the phy link up and down.
During registering the interrupt handler, it used IRQF_TRIGGER_FALLING
flag. But this flag has to be retrieved from device tree instead of hard
coding in the driver, so removing the flag.

Fixes: ff319a644829 ("net: dsa: microchip: move interrupt handling logic from lan937x to ksz_common")
Reported-by: Christian Eggers 
Signed-off-by: Arun Ramadoss 
Link: https://lore.kernel.org/r/20221213101440.24667-1-arun.ramadoss@microchip.com
Signed-off-by: Jakub Kicinski

net: dsa: microchip: add stats64 support for ksz8 series of switches

2022-12-08T16:27:27+00:00

Add stats64 support for ksz8xxx series of switches.

Signed-off-by: Oleksij Rempel 
Link: https://lore.kernel.org/r/20221205052904.2834962-1-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski

net: dsa: microchip: ksz8: move all DSA configurations to one location

2022-12-07T10:57:58+00:00

To make the code more comparable to KSZ9477 code, move DSA
configurations to the same location.

Signed-off-by: Oleksij Rempel 
Acked-by: Arun Ramadoss 
Reviewed-by: Vladimir Oltean 
Signed-off-by: Paolo Abeni

net: dsa: microchip: enable MTU normalization for KSZ8795 and KSZ9477 compatible switches

2022-12-07T10:57:58+00:00

KSZ8795 and KSZ9477 compatible series of switches use global max frame
size configuration register. So, enable MTU normalization for this reason.

Signed-off-by: Oleksij Rempel 
Acked-by: Arun Ramadoss 
Reviewed-by: Vladimir Oltean 
Signed-off-by: Paolo Abeni

net: dsa: microchip: ksz8: add MTU configuration support

2022-12-07T10:57:58+00:00

Make MTU configurable on KSZ87xx and KSZ88xx series of switches.

Before this patch, pre-configured behavior was different on different
switch series, due to opposite meaning of the same bit:
- KSZ87xx: Reg 4, Bit 1 - if 1, max frame size is 1532; if 0 - 1514
- KSZ88xx: Reg 4, Bit 1 - if 1, max frame size is 1514; if 0 - 1532

Since the code was telling "... SW_LEGAL_PACKET_DISABLE, true)", I
assume, the idea was to set max frame size to 1532.

With this patch, by setting MTU size 1500, both switch series will be
configured to the 1532 frame limit.

This patch was tested on KSZ8873.

Signed-off-by: Oleksij Rempel 
Acked-by: Arun Ramadoss 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
Signed-off-by: Paolo Abeni

net: dsa: microchip: add ksz_rmw8() function

2022-12-07T10:57:58+00:00

Add ksz_rmw8(), it will be used in the next patch.

Signed-off-by: Oleksij Rempel 
Acked-by: Arun Ramadoss 
Reviewed-by: Florian Fainelli 
Signed-off-by: Paolo Abeni

net: dsa: microchip: do not store max MTU for all ports

2022-12-07T10:57:58+00:00

If we have global MTU configuration, it is enough to configure it on CPU
port only.

Signed-off-by: Oleksij Rempel 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
Signed-off-by: Paolo Abeni