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.
next prev parent 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).