netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Richard Cochran <richardcochran@gmail.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Alexandru Marginean <alexandru.marginean@nxp.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
	Hongbo Wang <hongbo.wang@nxp.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Po Liu <po.liu@nxp.com>, Yangbo Lu <yangbo.lu@nxp.com>,
	Maxim Kochetkov <fido_max@inbox.ru>,
	Eldar Gasanov <eldargasanov2@gmail.com>,
	Andrey L <al@b4comtech.com>,
	Tobias Waldekranz <tobias@waldekranz.com>,
	UNGLinuxDriver@microchip.com
Subject: Re: [PATCH v5 net-next 07/10] net: dsa: allow changing the tag protocol via the "tagging" device attribute
Date: Thu, 21 Jan 2021 14:23:14 +0200	[thread overview]
Message-ID: <20210121122314.2jfxuwu2cpokx3w5@skbuf> (raw)
In-Reply-To: <9c5f179b-056b-f513-6500-eb36f9f8df0e@gmail.com>

Hi Florian,

On Wed, Jan 20, 2021 at 07:53:41PM -0800, Florian Fainelli wrote:
> > +static int dsa_switch_tag_proto_del(struct dsa_switch *ds,
> > +				    struct dsa_notifier_tag_proto_info *info)
> > +{
> > +	int err = 0, port;
> > +
> > +	for (port = 0; port < ds->num_ports; port++) {
> > +		if (!dsa_switch_tag_proto_match(ds, port, info))
> > +			continue;
> > +
> > +		/* Check early if we can replace it, so we don't delete it
> > +		 * for nothing and leave the switch dangling.
> > +		 */
> > +		if (!ds->ops->set_tag_protocol) {
> > +			err = -EOPNOTSUPP;
> > +			break;
> > +		}
> 
> This can be moved out of the loop.

Thanks a lot for reviewing.
Yes, you are right, this can be moved out. It is a left-over from using
dsa_broadcast in the previous version. It is not the only left-over: the
info->tree_index is now redundant because we are notifying within a
single DSA switch tree.

> > +
> > +		/* The delete method is optional, just the setter
> > +		 * is mandatory
> > +		 */
> > +		if (ds->ops->del_tag_protocol)
> > +			ds->ops->del_tag_protocol(ds, port,
> > +						  info->tag_ops->proto);
> > +	}
> > +
> > +	return err;
> > +}
> > +
> > +static int dsa_switch_tag_proto_set(struct dsa_switch *ds,
> > +				    struct dsa_notifier_tag_proto_info *info)
> > +{
> > +	bool proto_changed = false;
> > +	int port, err;
> > +
> > +	for (port = 0; port < ds->num_ports; port++) {
> > +		struct dsa_port *cpu_dp = dsa_to_port(ds, port);
> > +
> > +		if (!dsa_switch_tag_proto_match(ds, port, info))
> > +			continue;
> > +
> > +		err = ds->ops->set_tag_protocol(ds, cpu_dp->index,
> > +						info->tag_ops->proto);
> > +		if (err)
> > +			return err;
> 
> Don't you need to test for ds->ops->set_tag_protocol to be implemented
> before calling it? Similar comment to earlier, can we do an early check
> for the operation being supported outside of the loop?

My assumption was that I had already added the check in tag_proto_del.
There are no code paths that call one but not the other. I can add the
check here too.

There's one more thing I would change: the dsa_switch_tag_proto_match.
Right now I am matching only on the CPU port, but if I take a look at
the mv88e6xxx driver:

static int mv88e6xxx_setup_port_mode(struct mv88e6xxx_chip *chip, int port)
{
	if (dsa_is_dsa_port(chip->ds, port))
		return mv88e6xxx_set_port_mode_dsa(chip, port);

	if (dsa_is_user_port(chip->ds, port))
		return mv88e6xxx_set_port_mode_normal(chip, port);

	/* Setup CPU port mode depending on its supported tag format */
	if (chip->info->tag_protocol == DSA_TAG_PROTO_DSA)
		return mv88e6xxx_set_port_mode_dsa(chip, port);

	if (chip->info->tag_protocol == DSA_TAG_PROTO_EDSA)
		return mv88e6xxx_set_port_mode_edsa(chip, port);

	return -EINVAL;
}

DSA links call the same function as CPU ports configured for
DSA_TAG_PROTO_DSA. So to cater to Marvell switches too, and to ease a
potential conversion to this API, I could add dsa_is_dsa_port to the
matching function too.

  reply	other threads:[~2021-01-21 12:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21  2:36 [PATCH v5 net-next 00/10] tag_8021q for Ocelot switches Vladimir Oltean
2021-01-21  2:36 ` [PATCH v5 net-next 01/10] net: dsa: tag_8021q: add helpers to deduce whether a VLAN ID is RX or TX VLAN Vladimir Oltean
2021-01-21  2:36 ` [PATCH v5 net-next 02/10] net: mscc: ocelot: export VCAP structures to include/soc/mscc Vladimir Oltean
2021-01-21  2:36 ` [PATCH v5 net-next 03/10] net: mscc: ocelot: store a namespaced VCAP filter ID Vladimir Oltean
2021-01-21  2:36 ` [PATCH v5 net-next 04/10] net: mscc: ocelot: reapply bridge forwarding mask on bonding join/leave Vladimir Oltean
2021-01-21  3:40   ` Florian Fainelli
2021-01-21  2:36 ` [PATCH v5 net-next 05/10] net: mscc: ocelot: don't use NPI tag prefix for the CPU port module Vladimir Oltean
2021-01-21  3:41   ` Florian Fainelli
2021-01-21  2:36 ` [PATCH v5 net-next 06/10] net: dsa: document the existing switch tree notifiers and add a new one Vladimir Oltean
2021-01-21  3:43   ` Florian Fainelli
2021-01-21  2:36 ` [PATCH v5 net-next 07/10] net: dsa: allow changing the tag protocol via the "tagging" device attribute Vladimir Oltean
2021-01-21  3:53   ` Florian Fainelli
2021-01-21 12:23     ` Vladimir Oltean [this message]
2021-01-21  2:36 ` [PATCH v5 net-next 08/10] net: dsa: felix: convert to the new .{set,del}_tag_protocol DSA API Vladimir Oltean
2021-01-21  4:02   ` Florian Fainelli
2021-01-21  2:36 ` [PATCH v5 net-next 09/10] net: dsa: add a second tagger for Ocelot switches based on tag_8021q Vladimir Oltean
2021-01-21  4:05   ` Florian Fainelli
2021-01-21  2:36 ` [PATCH v5 net-next 10/10] net: dsa: felix: perform switch setup for tag_8021q Vladimir Oltean
2021-01-21  4:10   ` Florian Fainelli

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=20210121122314.2jfxuwu2cpokx3w5@skbuf \
    --to=olteanv@gmail.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=al@b4comtech.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=alexandru.marginean@nxp.com \
    --cc=andrew@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=eldargasanov2@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=fido_max@inbox.ru \
    --cc=hongbo.wang@nxp.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=po.liu@nxp.com \
    --cc=richardcochran@gmail.com \
    --cc=tobias@waldekranz.com \
    --cc=vivien.didelot@gmail.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=xiaoliang.yang_1@nxp.com \
    --cc=yangbo.lu@nxp.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).