Message-ID: <27ccf5c4-db66-491c-aa7c-29b83ebfca3a@fris.de>
Date: Fri, 15 Aug 2025 20:30:13 +0200
From: Frieder Schrempf <frieder@...s.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 linux-kernel@...r.kernel.org, Lukasz Majewski <lukma@...x.de>,
 Paolo Abeni <pabeni@...hat.com>, UNGLinuxDriver@...rochip.com,
 Vladimir Oltean <olteanv@...il.com>, Woojung Huh
 <woojung.huh@...rochip.com>, Frieder Schrempf <frieder.schrempf@...tron.de>,
 Florian Fainelli <florian.fainelli@...adcom.com>,
 Jesse Van Gavere <jesseevg@...il.com>,
 Oleksij Rempel <o.rempel@...gutronix.de>,
 Pieter Van Trappen <pieter.van.trappen@...n.ch>,
 "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
 Simon Horman <horms@...nel.org>, Tristram Ha <tristram.ha@...rochip.com>,
 Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Subject: Re: [RFC PATCH] net: dsa: microchip: Prevent overriding of HSR port
 forwarding

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@...tron.de>
>>
>> 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.

Powered by blists - more mailing lists