From: Lukasz Majewski <lukma@denx.de>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
Oleksij Rempel <o.rempel@pengutronix.de>,
Tristram.Ha@microchip.com,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Simon Horman <horms@kernel.org>,
Dan Carpenter <dan.carpenter@linaro.org>,
"Ricardo B. Marliere" <ricardo@marliere.net>,
Casper Andersson <casper.casan@gmail.com>,
linux-kernel@vger.kernel.org,
Woojung Huh <woojung.huh@microchip.com>,
UNGLinuxDriver@microchip.com, Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH v2 net-next] net: dsa: Allow only up to two HSR HW offloaded ports for KSZ9477
Date: Wed, 19 Jun 2024 17:10:57 +0200 [thread overview]
Message-ID: <20240619171057.766c657b@wsk> (raw)
In-Reply-To: <20240619144243.cp6ceembrxs27tfc@skbuf>
[-- Attachment #1: Type: text/plain, Size: 4116 bytes --]
Hi Vladimir,
> On Wed, Jun 19, 2024 at 03:42:48PM +0200, Lukasz Majewski wrote:
> > The KSZ9477 allows HSR in-HW offloading for any of two selected
> > ports. This patch adds check if one tries to use more than two
> > ports with HSR offloading enabled.
> >
> > The problem is with RedBox configuration (HSR-SAN) - when
> > configuring: ip link add name hsr0 type hsr slave1 lan1 slave2 lan2
> > interlink lan3 \ supervision 45 version 1
> >
> > The lan1 (port0) and lan2 (port1) are correctly configured as
> > ports, which can use HSR offloading on ksz9477.
> >
> > However, when we do already have two bits set in hsr_ports, we need
> > to return (-ENOTSUPP), so the interlink port (lan3) would be used
> > with
>
> EOPNOTSUPP
>
> > SW based HSR RedBox support.
> >
> > Otherwise, I do see some strange network behavior, as some HSR
> > frames are visible on non-HSR network and vice versa.
> >
> > This causes the switch connected to interlink port (lan3) to drop
> > frames and no communication is possible.
> >
> > Moreover, conceptually - the interlink (i.e. HSR-SAN port -
> > lan3/port2) shall be only supported in software as it is also
> > possible to use ksz9477 with only SW based HSR (i.e. port0/1 ->
> > hsr0 with offloading, port2 -> HSR-SAN/interlink, port4/5 -> hsr1
> > with SW based HSR).
> >
> > Fixes: 5055cccfc2d1 ("net: hsr: Provide RedBox support (HSR-SAN)")
> > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> >
> > ---
> > Changes for v2:
> > - Add more verbose description with Fixes: tag
> > - Check the condition earlier and remove extra check if SoC is
> > ksz9477
> > - Add comment in the source code file
> > ---
> > drivers/net/dsa/microchip/ksz_common.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/net/dsa/microchip/ksz_common.c
> > b/drivers/net/dsa/microchip/ksz_common.c index
> > 2818e24e2a51..72bb419e34b0 100644 ---
> > a/drivers/net/dsa/microchip/ksz_common.c +++
> > b/drivers/net/dsa/microchip/ksz_common.c @@ -3906,6 +3906,13 @@
> > static int ksz_hsr_join(struct dsa_switch *ds, int port, struct
> > net_device *hsr, return -EOPNOTSUPP; }
> >
> > + /* KSZ9477 can only perform HSR offloading for up to two
> > ports */
> > + if (hweight8(dev->hsr_ports) >= 2) {
> > + NL_SET_ERR_MSG_MOD(extack,
> > + "Cannot offload more than two
> > ports - use software HSR");
> > + return -EOPNOTSUPP;
> > + }
> > +
> > /* Self MAC address filtering, to avoid frames traversing
> > * the HSR ring more than once.
> > */
> > --
> > 2.20.1
> >
>
> How do you know you are rejecting the offloading of the interlink
> port, and not of one of the ring ports?
It seems like iproute2 is providing the correct ordering (and assures
that lan3/port2 is called as a third one - please see below).
> Basing this off of calling
> order is fragile,
In the accepted form - yes - the interlink port is called as a third
one, so it is refused to configure it in the same way as ports, which
are supporting HSR in HW (i.e. offloading).
> and does not actually reflect the hardware
> limitation.
root@sama5d3-xplained-sd:~# ip link add name hsr0 type hsr slave1 lan1
interlink lan3 slave2 lan2 supervision 45 version 1
ksz-switch spi1.0
lan1: entered promiscuous mode ksz-switch spi1.0 lan2: entered
promiscuous mode ksz-switch spi1.0 lan3: entered promiscuous mode
port: 2
Warning: ksz_switch: Cannot offload more than two ports - using
software HSR.
Gives the same output as:
root@sama5d3-xplained-sd:~# ip link add name hsr0 type hsr slave1 lan1
slave2 lan2 interlink lan3 supervision 45 version 1
ksz-switch spi1.0
lan1: entered promiscuous mode ksz-switch spi1.0 lan2: entered
promiscuous mode ksz-switch spi1.0 lan3: entered promiscuous mode
port: 2
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-06-19 15:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 13:42 [PATCH v2 net-next] net: dsa: Allow only up to two HSR HW offloaded ports for KSZ9477 Lukasz Majewski
2024-06-19 13:54 ` Dan Carpenter
2024-06-19 14:27 ` Andrew Lunn
2024-06-19 14:42 ` Vladimir Oltean
2024-06-19 15:10 ` Lukasz Majewski [this message]
2024-06-19 15:48 ` Vladimir Oltean
2024-06-19 15:59 ` Vladimir Oltean
2024-06-20 7:59 ` Lukasz Majewski
2024-06-20 9:02 ` Vladimir Oltean
2024-06-20 12:00 ` Lukasz Majewski
2024-06-20 12:06 ` Vladimir Oltean
2024-06-20 13:28 ` Lukasz Majewski
2024-06-20 14:33 ` Vladimir Oltean
2024-06-21 8:31 ` Lukasz Majewski
2024-06-21 8:43 ` Vladimir Oltean
2024-06-19 21:54 ` Vladimir Oltean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240619171057.766c657b@wsk \
--to=lukma@denx.de \
--cc=Tristram.Ha@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=bigeasy@linutronix.de \
--cc=casper.casan@gmail.com \
--cc=dan.carpenter@linaro.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=ricardo@marliere.net \
--cc=woojung.huh@microchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.