All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: Vladimir Oltean <olteanv@gmail.com>
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 13:23:51 +0200	[thread overview]
Message-ID: <20230905132351.2e129d53@wsk> (raw)
In-Reply-To: <20230905104725.zy3lwbxjhqhqyzdj@skbuf>

[-- Attachment #1: Type: text/plain, Size: 5541 bytes --]

Hi Vladimir,

> On Mon, Sep 04, 2023 at 02:02:09PM +0200, Lukasz Majewski wrote:
> > This patch provides the common KSZ (i.e. Microchip) DSA code with
> > support for HSR aware devices.
> > 
> > To be more specific - generic ksz_hsr_{join|leave} functions are
> > provided, now only supporting KSZ9477 IC.
> > 
> > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > ---
> > Changes for v2:
> > - None
> > 
> > Changes for v3:
> > - Do not return -EOPNOTSUPP for only PRP_V1 (as v2 will not be
> > caught)  
> 
> Should be squashed into patch 3/4. The split does not make the code
> easier to review for me.

So you recommend to have only one patch in which the hsr_join{leave}
function from ksz_common.c and ksz9477_hsr_join{leave} from ksz9477.c
are added?

> 
> > ---
> >  drivers/net/dsa/microchip/ksz_common.c | 69
> > ++++++++++++++++++++++++++ 1 file changed, 69 insertions(+)
> > 
> > diff --git a/drivers/net/dsa/microchip/ksz_common.c
> > b/drivers/net/dsa/microchip/ksz_common.c index
> > 579fde54d1e1..91d1acaf4494 100644 ---
> > a/drivers/net/dsa/microchip/ksz_common.c +++
> > b/drivers/net/dsa/microchip/ksz_common.c @@ -16,6 +16,7 @@
> >  #include <linux/etherdevice.h>
> >  #include <linux/if_bridge.h>
> >  #include <linux/if_vlan.h>
> > +#include <linux/if_hsr.h>
> >  #include <linux/irq.h>
> >  #include <linux/irqdomain.h>
> >  #include <linux/of_mdio.h>
> > @@ -3433,6 +3434,72 @@ u16 ksz_hsr_get_ports(struct dsa_switch *ds)
> >  	return 0;
> >  }
> >  
> > +static int ksz_hsr_join(struct dsa_switch *ds, int port, struct
> > net_device *hsr) +{
> > +	struct dsa_port *partner = NULL, *dp;
> > +	struct ksz_device *dev = ds->priv;
> > +	enum hsr_version ver;
> > +	int ret;
> > +
> > +	ret = hsr_get_version(hsr, &ver);
> > +	if (ret)
> > +		return ret;
> > +
> > +	switch (dev->chip_id) {
> > +	case KSZ9477_CHIP_ID:
> > +		if (!(ver == HSR_V0 || ver == HSR_V1))
> > +			return -EOPNOTSUPP;  
> 
> move the "default: return -EOPNOTSUPP" statement from below here.
> 

Ok, I will add default statement with -EOPNOTSUPP.

> > +	}  
> 
> I don't see any restriction to allow offloading a single HSR device.

As I've written in the other response - I've followed the xrs700x.c
convention. 

Moreover, for me it seems more natural, that we only allow full HSR
support for 2 ports or none. Please be aware, that HSR supposed to
support only 2 ports, and having only one working is not recommended by
vendor.

> Looking at patch 3/4, that will obviously not work due to some
> hardware registers which are global and would be overwritten by the
> second HSR device.

I cannot guarantee that there will not be any "side effects" with this
approach. And to be honest - I would prefer to spent time on testing
recommended setups.

> 
> For example, a5psw_port_bridge_join() has a similar restriction to
> offload a single bridge device.

HSR is IMHO a bit different than plain "bridge" offloading.

> 
> If you return -EOPNOTSUPP, then DSA should fall back to an
> unoffloaded, 100% software-based HSR device, and that should work
> too. 

And then we would have one port with SW HSR and another one with HW
HSR?

>It would be good if you could verify that the unoffloaded HSR
> works well after the changes too.

I've tested on KSZ9477-EVB the SW HSR operation with two ports (and two
or three boards) and HW HSR offloading. Results are presented in the
cover-letter.

> 
> > +
> > +	/* We can't enable redundancy on the switch until both
> > +	 * redundant ports have signed up.
> > +	 */
> > +	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_join(ds, port, hsr, partner);
> > +	default:
> > +		return -EOPNOTSUPP;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +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;
> > +}
> > +
> >  static const struct dsa_switch_ops ksz_switch_ops = {
> >  	.get_tag_protocol	= ksz_get_tag_protocol,
> >  	.connect_tag_protocol   = ksz_connect_tag_protocol,
> > @@ -3452,6 +3519,8 @@ static const struct dsa_switch_ops
> > ksz_switch_ops = { .get_sset_count		= ksz_sset_count,
> >  	.port_bridge_join	= ksz_port_bridge_join,
> >  	.port_bridge_leave	= ksz_port_bridge_leave,
> > +	.port_hsr_join		= ksz_hsr_join,
> > +	.port_hsr_leave		= ksz_hsr_leave,
> >  	.port_stp_state_set	= ksz_port_stp_state_set,
> >  	.port_pre_bridge_flags	= ksz_port_pre_bridge_flags,
> >  	.port_bridge_flags	= ksz_port_bridge_flags,
> > -- 
> > 2.20.1
> >   
> 




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 --]

  reply	other threads:[~2023-09-05 16:51 UTC|newest]

Thread overview: 25+ 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-07  8:18   ` kernel test robot
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 [this message]
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

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=20230905132351.2e129d53@wsk \
    --to=lukma@denx.de \
    --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=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=olteanv@gmail.com \
    --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 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.