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.