From: Vladimir Oltean <olteanv@gmail.com>
To: Lukasz Majewski <lukma@denx.de>
Cc: Tristram.Ha@microchip.com, Eric Dumazet <edumazet@google.com>,
Andrew Lunn <andrew@lunn.ch>,
davem@davemloft.net, Woojung Huh <woojung.huh@microchip.com>,
Oleksij Rempel <o.rempel@pengutronix.de>,
Florian Fainelli <f.fainelli@gmail.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
UNGLinuxDriver@microchip.com,
Oleksij Rempel <linux@rempel-privat.de>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [[RFC PATCH v4 net-next] 0/2] net: dsa: hsr: Enable HSR HW offloading for KSZ9477
Date: Tue, 12 Sep 2023 17:26:44 +0300 [thread overview]
Message-ID: <20230912142644.u4sdkveei3e5hwaf@skbuf> (raw)
In-Reply-To: <20230912160326.188e1d13@wsk> <20230912160326.188e1d13@wsk>
On Tue, Sep 12, 2023 at 04:03:26PM +0200, Lukasz Majewski wrote:
> > In any case, as long as it's the DSA master's address that we program
> > to hardware, then I see it as inevitable to add a new struct
> > dsa_switch_ops :: master_addr_change() function
>
> Please correct my understanding. The above change would affect the
> whole DSA subsystem. It would require to have the core DSA modified and
> would affect its operation?
Uhm, yes, that would be the idea. If we were going to track changes to
the DSA master's MAC address, we should do it from the DSA framework
which has the existing netdev notifier listener infrastructure in place.
> > Or you can argue that dragging the DSA master into the discussion
> > about how we should program REG_SW_MAC_ADDR_0 is a complication.
>
> Yes, it is IMHO the complication.
Ok, it's a point of view.
> git grep -n "REG_SW_MAC_ADDR_0"
> drivers/net/dsa/microchip/ksz8795_reg.h:326:#define REG_SW_MAC_ADDR_0
> 0x68
> drivers/net/dsa/microchip/ksz9477.c:1194:
> ksz_write8(dev, REG_SW_MAC_ADDR_0 + i,
>
> drivers/net/dsa/microchip/ksz9477_reg.h:169:#define REG_SW_MAC_ADDR_0
> 0x0302
>
> In the current net-next the REG_SW_MAC_ADDR_0 is altered used (the only
> usage are now with mine patches on ksz9477).
>
> To sum up:
>
> 1. Up till now in (net-next) REG_SW_MAC_ADDR_0 is ONLY declared for
> Microchip switches. No risk for access - other than HSR patches.
I know (except for Oleksij's WoL patches, which will eventually be
resubmitted).
> 2. The MAC address alteration of DSA master and propagation to slaves
> is a generic DSA bug.
Which can be/will be fixed. The diff I've included in the question to
Jakub closes it, in fact.
> Considering the above - the HSR implementation is safe (to the extend
> to the whole DSA subsystem current operation). Am I correct?
If we exclude the aforementioned bug (which won't be a bug forever),
there still exists the case where the MAC address of a DSA user port can
be changed. The HSR driver has a NETDEV_CHANGEADDR handler for this as
well, and updates its own MAC address to follow the port. If that is
allowed to happen after the offload, currently it will break the offload.
next prev parent reply other threads:[~2023-09-12 14:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 15:27 [[RFC PATCH v4 net-next] 0/2] net: dsa: hsr: Enable HSR HW offloading for KSZ9477 Lukasz Majewski
2023-09-06 15:28 ` [[RFC PATCH v4 net-next] 1/2] net: dsa: Extend ksz9477 TAG setup to support HSR frames duplication Lukasz Majewski
2023-09-06 15:28 ` [[RFC PATCH v4 net-next] 2/2] net: dsa: hsr: Enable in KSZ9477 switch HW HSR offloading Lukasz Majewski
2023-09-11 14:58 ` [[RFC PATCH v4 net-next] 0/2] net: dsa: hsr: Enable HSR HW offloading for KSZ9477 Lukasz Majewski
2023-09-11 16:05 ` Vladimir Oltean
2023-09-11 17:02 ` Vladimir Oltean
2023-09-11 17:03 ` Vladimir Oltean
2023-10-03 13:34 ` Jakub Kicinski
2023-09-12 8:17 ` Lukasz Majewski
2023-09-12 9:29 ` Vladimir Oltean
2023-09-12 14:03 ` Lukasz Majewski
2023-09-12 14:26 ` Vladimir Oltean [this message]
2023-09-12 15:06 ` Lukasz Majewski
2023-09-12 21:55 ` Vladimir Oltean
2023-09-13 8:22 ` Lukasz Majewski
2023-09-13 10:58 ` Vladimir Oltean
2023-09-13 12:15 ` Lukasz Majewski
2023-09-13 13:51 ` Vladimir Oltean
2023-09-13 18:42 ` Vladimir Oltean
2023-09-14 21:18 ` Lukasz Majewski
2023-09-15 14:22 ` Vladimir Oltean
2023-09-18 9:06 ` Lukasz Majewski
2023-09-14 20:45 ` Lukasz Majewski
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=20230912142644.u4sdkveei3e5hwaf@skbuf \
--to=olteanv@gmail.com \
--cc=Tristram.Ha@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rempel-privat.de \
--cc=lukma@denx.de \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).