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: Thu, 20 Jun 2024 09:59:20 +0200 [thread overview]
Message-ID: <20240620095920.6035022d@wsk> (raw)
In-Reply-To: <20240619155928.wmivi4lckjq54t3w@skbuf>
[-- Attachment #1: Type: text/plain, Size: 2294 bytes --]
Hi Vladimir,
> On Wed, Jun 19, 2024 at 06:48:14PM +0300, Vladimir Oltean wrote:
> > Granted, this isn't an actual functional problem, but given that you
> > are fixing a newly developed feature for net-next, and that this is
> > API that gets progressively harder to change as more devices
> > implement offloads, I would expect a more obvious signaling
> > mechanism to exist for this, and now seems a good time to do it,
> > rather than opting for the most minimal fix.
>
> Actually I'm not even so sure about this basic fact, that it isn't a
> functional problem already.
>
> xrs700x_hsr_join() has explicit checks for port 1 and 2. Obviously it
> expects those ports to be ring ports.
Yes.
>
> But if you configure from user space ports 0 and 1 to be ring ports,
> and port 2 to be an interlink port, the kernel will accept that
> configuration.
Yes.
> It will return -EOPNOTSUPP for port 0,
This comment is for xrs700x_hsr_join()?
For the ksz_hsr_join() we do explicitly check for the KSZ9477_CHIP_ID.
I do regard this fix as a ksz9477 specific one, as there are some
issues (IMHO - this is the "unexpected behaviour" case for this IC) when
we add interlink to SoC VLAN.
I don't understand why you bring up xrs700x case here? Is it to get a
"broader context"?
> falling back to
> software mode for the first ring port, then accept offload for ring
> ports 1 and 2. But it doesn't match what user space requested, because
> port 2 should be interlink...
Please correct me if I'm wrong, but this seems to not be the case for
ksz9477 - as I stated in the other mail - the ordering is correct (I've
checked it).
>
> I think you really should pass the port type down to drivers and
> reject offloading interlink ports...
As stated above - IMHO I do provide a fix for this particular IC
(KSZ9477). With xrs700x we do have fixed ports supporting HSR (port
1,2), so there is no other choice. As a result the HSR Interlink would
be supporting only SW emulation.
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-20 7:59 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
2024-06-19 15:48 ` Vladimir Oltean
2024-06-19 15:59 ` Vladimir Oltean
2024-06-20 7:59 ` Lukasz Majewski [this message]
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=20240620095920.6035022d@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.