[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250814092309.1534e1b4@wsk>
Date: Thu, 14 Aug 2025 09:23:09 +0200
From: Łukasz Majewski <lukma@...ladev.com>
To: Frieder Schrempf <frieder.schrempf@...tron.de>
Cc: Frieder Schrempf <frieder@...s.de>, netdev@...r.kernel.org, Andrew Lunn
<andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
linux-kernel@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
UNGLinuxDriver@...rochip.com, Vladimir Oltean <olteanv@...il.com>, Woojung
Huh <woojung.huh@...rochip.com>, 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
On Wed, 13 Aug 2025 17:57:02 +0200
Frieder Schrempf <frieder.schrempf@...tron.de> wrote:
> Am 13.08.25 um 17:45 schrieb Łukasz Majewski:
> > [Sie erhalten nicht h?ufig E-Mails von lukma@...ladev.com. Weitere
> > Informationen, warum dies wichtig ist, finden Sie unter
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Hi Frieder,
> >
> >> 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
> >>
> >> In this state, packets will not get forwarded between the HSR ports
> >> and communication between HSR nodes that are not direct neighbours
> >> in the topology fails.
> >>
> >> To avoid this, we prevent all forwarding reconfiguration requests
> >> for ports that are part of a HSR setup with NETIF_F_HW_HSR_FWD
> >> enabled.
> >>
> >> Fixes: 2d61298fdd7b ("net: dsa: microchip: Enable HSR offloading
> >> for KSZ9477") Signed-off-by: Frieder Schrempf
> >> <frieder.schrempf@...tron.de> ---
> >> I'm posting this as RFC as my knowledge of the driver and the
> >> stack in general is very limited. Please review thoroughly and
> >> provide feedback. Thanks!
> >
> > I don't have the HW at hand at the moment (temporary).
> >
> > Could you check if this patch works when you create two hsr
> > interfaces
> > - i.e. hsr1 would use HW offloading from KSZ9744 and hsr2 is just
> > the one supporting HSR in software.
>
> My hardware only has three user ports. So that might get a bit
> difficult to test. I will try to configure one unconnected port to
> set up two HSR links, but I won't be able to fully test this due to
> the lack of the fourth physical link.
>
Ok, I see...
I was using the Atmel's/Microchip Devel board with 5 ports...
--
Best regards,
Lukasz Majewski
--
Nabla Software Engineering GmbH
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: office@...ladev.com
Geschftsfhrer : Stefano Babic
Powered by blists - more mailing lists