All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: George McCollister <george.mccollister@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Tobias Waldekranz <tobias@waldekranz.com>,
	Jonathan Corbet <corbet@lwn.net>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next v3 4/4] net: dsa: xrs700x: add HSR offloading support
Date: Wed, 10 Feb 2021 11:49:54 +0200	[thread overview]
Message-ID: <20210210094954.7fi4bhh6dboa6s5i@skbuf> (raw)
In-Reply-To: <f5b361ec-c8a1-22b7-42b3-94fbe4387525@gmail.com>

On Tue, Feb 09, 2021 at 08:11:15PM -0800, Florian Fainelli wrote:
> 
> 
> On 2/9/2021 5:02 PM, George McCollister wrote:
> > Add offloading for HSR/PRP (IEC 62439-3) tag insertion, tag removal
> > forwarding and duplication supported by the xrs7000 series switches.
> > 
> > Only HSR v1 and PRP v1 are supported by the xrs7000 series switches (HSR
> > v0 is not).
> > 
> > Signed-off-by: George McCollister <george.mccollister@gmail.com>
> > ---
> [snip]
> > +	val &= ~BIT(dsa_upstream_port(ds, port));
> > +	regmap_write(priv->regmap, XRS_PORT_FWD_MASK(partner->index), val);
> > +	regmap_write(priv->regmap, XRS_PORT_FWD_MASK(port), val);
> > +
> > +	regmap_fields_write(priv->ps_forward, partner->index,
> > +			    XRS_PORT_FORWARDING);
> > +	regmap_fields_write(priv->ps_forward, port, XRS_PORT_FORWARDING);
> > +
> > +	hsr_pair[0] = port;
> > +	hsr_pair[1] = partner->index;
> > +	for (i = 0; i < ARRAY_SIZE(hsr_pair); i++) {
> > +		slave = dsa_to_port(ds, hsr_pair[i])->slave;
> > +		slave->features |= XRS7000X_SUPPORTED_HSR_FEATURES;
> 
> It's a bit weird to change the supported features while joining, usually
> you set them ahead of time to indicate what you are capable of doing and
> those can get toggled by user-space to enable/disable said feature, I
> suppose the goal here is to influence the HSR data path's decisions to
> insert or not tags so this may be okay. This does beg several questions:
> 
> - should slave->vlan_features also include that feature set somehow (can
> I have a VLAN upper?)

hsr_check_dev_ok:
	if (is_vlan_dev(dev)) {
		NL_SET_ERR_MSG_MOD(extack, "HSR on top of VLAN is not yet supported in this driver.");
		return -EINVAL;
	}

> - should there be a notifier running to advertise NETDEV_FEAT_CHANGE?

I felt it's a bit weird too to toggle the netdev flags just like that
instead of just enabling them at probe time or something (or have DSA
set them in dsa_slave_create(), just as it currently checks
ds->ops->port_vlan_add), but since there's no need for anyone to process
that notification, and there don't appear to be any strict guidelines, I
didn't say anything. I guess the current code is just fine for what is
needed at the moment.

Reviewed-by: Vladimir Oltean <olteanv@gmail.com>

  reply	other threads:[~2021-02-10  9:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-10  1:02 [PATCH net-next v3 0/4] add HSR offloading support for DSA switches George McCollister
2021-02-10  1:02 ` [PATCH net-next v3 1/4] net: hsr: generate supervision frame without HSR/PRP tag George McCollister
2021-02-10  9:33   ` Vladimir Oltean
2021-02-10  1:02 ` [PATCH net-next v3 2/4] net: hsr: add offloading support George McCollister
2021-02-10  9:37   ` Vladimir Oltean
2021-02-10  1:02 ` [PATCH net-next v3 3/4] net: dsa: add support for offloading HSR George McCollister
2021-02-10  4:04   ` Florian Fainelli
2021-02-10  9:44   ` Vladimir Oltean
2021-02-10  1:02 ` [PATCH net-next v3 4/4] net: dsa: xrs700x: add HSR offloading support George McCollister
2021-02-10  4:11   ` Florian Fainelli
2021-02-10  9:49     ` Vladimir Oltean [this message]
2021-02-11 22:00 ` [PATCH net-next v3 0/4] add HSR offloading support for DSA switches patchwork-bot+netdevbpf

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=20210210094954.7fi4bhh6dboa6s5i@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=f.fainelli@gmail.com \
    --cc=george.mccollister@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tobias@waldekranz.com \
    --cc=vivien.didelot@gmail.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.