From: Vladimir Oltean <olteanv@gmail.com>
To: Lukasz Majewski <lukma@denx.de>
Cc: Eric Dumazet <edumazet@google.com>, Andrew Lunn <andrew@lunn.ch>,
davem@davemloft.net, Paolo Abeni <pabeni@redhat.com>,
Woojung Huh <woojung.huh@microchip.com>,
Tristram.Ha@microchip.com,
Florian Fainelli <f.fainelli@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
UNGLinuxDriver@microchip.com,
George McCollister <george.mccollister@gmail.com>,
Oleksij Rempel <o.rempel@pengutronix.de>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 RFC 4/4] net: dsa: hsr: Provide generic HSR ksz_hsr_{join|leave} functions
Date: Tue, 5 Sep 2023 17:04:23 +0300 [thread overview]
Message-ID: <20230905140423.weisoaygc2tjvezb@skbuf> (raw)
In-Reply-To: <20230904120209.741207-5-lukma@denx.de>
On Mon, Sep 04, 2023 at 02:02:09PM +0200, Lukasz Majewski wrote:
> +static int ksz_hsr_leave(struct dsa_switch *ds, int port,
> + struct net_device *hsr)
> +{
> + struct dsa_port *partner = NULL, *dp;
> + struct ksz_device *dev = ds->priv;
> +
> + dsa_hsr_foreach_port(dp, ds, hsr) {
> + if (dp->index != port) {
> + partner = dp;
> + break;
> + }
> + }
> +
> + if (!partner)
> + return 0;
> +
> + switch (dev->chip_id) {
> + case KSZ9477_CHIP_ID:
> + return ksz9477_hsr_leave(ds, port, hsr, partner);
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
It's hard for me to put this in the proper perspective in this email,
since ksz9477_hsr_leave() is implemented in a different patch, so I'm
just going to reproduce it here:
int ksz9477_hsr_leave(struct dsa_switch *ds, int port, struct net_device *hsr,
struct dsa_port *partner)
{
struct ksz_device *dev = ds->priv;
/* Clear ports HSR support */
ksz_write32(dev, REG_HSR_PORT_MAP__4, 0);
/* Disable forwarding frames between HSR ports */
ksz_prmw32(dev, port, REG_PORT_VLAN_MEMBERSHIP__4, dev->hsr_ports, 0);
ksz_prmw32(dev, partner->index, REG_PORT_VLAN_MEMBERSHIP__4,
dev->hsr_ports, 0);
/* Disable per port self-address filtering */
ksz_port_cfg(dev, port, REG_PORT_LUE_CTRL, PORT_SRC_ADDR_FILTER, false);
ksz_port_cfg(dev, partner->index, REG_PORT_LUE_CTRL,
PORT_SRC_ADDR_FILTER, false);
return 0;
}
The code pattern from ksz_hsr_leave() is to disable HSR offload in both
member ports, after *both* member ports have left the HSR device, correct?
So it means that after this set of commands:
ip link add name hsr0 type hsr slave1 lan1 slave2 lan2 supervision 45 version 1
ip link set dev lan1 up
ip link set dev lan2 up
ip link set lan1 nomaster
lan1 will still have HSR offload enabled, and forwarding enabled towards
lan2, correct? That's not good, because lan1 is now a standalone port
and should operate as such.
prev parent reply other threads:[~2023-09-05 14:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-04 12:02 [PATCH v3 RFC 0/4] net: dsa: hsr: Enable HSR HW offloading for KSZ9477 Lukasz Majewski
2023-09-04 12:02 ` [PATCH v3 RFC 1/4] net: dsa: Extend the ksz_device structure to hold info about HSR ports Lukasz Majewski
2023-09-04 12:02 ` [PATCH v3 RFC 2/4] net: dsa: Extend ksz9477 TAG setup to support HSR frames duplication Lukasz Majewski
2023-09-05 10:22 ` Vladimir Oltean
2023-09-05 10:44 ` Lukasz Majewski
2023-09-05 11:00 ` Vladimir Oltean
2023-09-05 11:33 ` Lukasz Majewski
2023-09-04 12:02 ` [PATCH v3 RFC 3/4] net: dsa: hsr: Enable in KSZ9477 switch HW HSR offloading Lukasz Majewski
2023-09-05 10:37 ` Vladimir Oltean
2023-09-05 11:11 ` Lukasz Majewski
2023-09-05 13:03 ` Vladimir Oltean
2023-09-05 13:48 ` Vladimir Oltean
2023-09-05 15:20 ` Lukasz Majewski
2023-09-05 15:20 ` Lukasz Majewski
2023-09-04 12:02 ` [PATCH v3 RFC 4/4] net: dsa: hsr: Provide generic HSR ksz_hsr_{join|leave} functions Lukasz Majewski
2023-09-04 20:53 ` Vladimir Oltean
2023-09-05 9:12 ` Lukasz Majewski
2023-09-05 10:47 ` Vladimir Oltean
2023-09-05 11:23 ` Lukasz Majewski
2023-09-05 12:05 ` Vladimir Oltean
2023-09-05 12:23 ` Andrew Lunn
2023-09-05 13:47 ` Lukasz Majewski
2023-09-05 13:57 ` Vladimir Oltean
2023-09-05 14:04 ` Vladimir Oltean [this message]
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=20230905140423.weisoaygc2tjvezb@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=george.mccollister@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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).