Re: [RFC PATCH] net: dsa: microchip: Prevent overriding of HSR port forwarding

From: Frieder Schrempf
Date: Fri Aug 15 2025 - 14:31:00 EST


Am 15.08.25 um 00:59 schrieb Andrew Lunn:
On Wed, Aug 13, 2025 at 05:26:12PM +0200, Frieder Schrempf wrote:
From: Frieder Schrempf <frieder.schrempf@xxxxxxxxxx>

The KSZ9477 supports NETIF_F_HW_HSR_FWD to forward packets between
HSR ports. This is set up when creating the HSR interface via
ksz9477_hsr_join() and ksz9477_cfg_port_member().

At the same time ksz_update_port_member() is called on every
state change of a port and reconfiguring the forwarding to the
default state which means packets get only forwarded to the CPU
port.

If the ports are brought up before setting up the HSR interface
and then the port state is not changed afterwards, everything works
as intended:

ip link set lan1 up
ip link set lan2 up
ip link add name hsr type hsr slave1 lan1 slave2 lan2 supervision 45 version 1
ip addr add dev hsr 10.0.0.10/24
ip link set hsr up

If the port state is changed after creating the HSR interface, this results
in a non-working HSR setup:

ip link add name hsr type hsr slave1 lan1 slave2 lan2 supervision 45 version 1
ip addr add dev hsr 10.0.0.10/24
ip link set lan1 up
ip link set lan2 up
ip link set hsr up

So, restating what i said in a different thread, what happens if only
software was used? No hardware offload.

Sorry, I don't understand what you are aiming at.

Yes, this issue is related to hardware offloading. As far as I know there is no option (for the user) to force HSR into SW-only mode. The KSZ9477 driver uses hardware offloading up to the capabilities of the HW by default.

Yes, if I disable the offloading by modifying the driver code as already described in the other thread, the issue can be fixed at the cost of loosing the HW acceleration. In this case the driver consistently configures the HSR ports to forward any packets to the CPU which then forwards them as needed.

With the driver code as-is, there are two conflicting values used for the register that configures the forwarding. One is set during the HSR setup and makes sure that HSR ports forward packets among each other (and not only to the CPU), the other is set while changing the link state of the HSR ports and causes the forwarding to only happen between each port and the CPU, therefore effectively disabling the HW offloading while the driver still assumes it is enabled.

This is obviously a problem that should be fixed in the driver as changing the link state of the ports *after* setup of the HSR is a completely valid operation that shouldn't break things like it currently does.