All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Pawel Dembicki <paweldembicki@gmail.com>
Cc: netdev@vger.kernel.org, Linus Wallej <linus.walleij@linaro.org>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dsa: vsc73xx: add support for vlan filtering
Date: Fri, 22 Jan 2021 00:45:05 +0200	[thread overview]
Message-ID: <20210121224505.nwfipzncw2h5d3rw@skbuf> (raw)
In-Reply-To: <20210120063019.1989081-1-paweldembicki@gmail.com>

Hi Pawel,

On Wed, Jan 20, 2021 at 07:30:18AM +0100, Pawel Dembicki wrote:
> This patch adds support for vlan filtering in vsc73xx driver.
> 
> After vlan filtering enable, CPU_PORT is configured as trunk, without
> non-tagged frames. This allows to avoid problems with transmit untagged
> frames because vsc73xx is DSA_TAG_PROTO_NONE.
> 
> Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>

What are the issues that are preventing you from getting rid of
DSA_TAG_PROTO_NONE? Not saying that making the driver VLAN aware is a
bad idea, but maybe also adding a tagging driver should really be the
path going forward. If there are hardware issues surrounding the native
tagging support, then DSA can make use of your VLAN features by
transforming them into a software-defined tagger, see
net/dsa/tag_8021q.c. But using a trunk CPU port with 8021q uppers on top
of the DSA master is a poor job of achieving that.

> ---
> +static int
> +vsc73xx_port_read_vlan_table_entry(struct dsa_switch *ds, u16 vid, u8 *portmap)
> +{
> +	struct vsc73xx *vsc = ds->priv;
> +	u32 val;
> +	int ret;
> +
> +	if (vid > 4095)
> +		return -EPERM;

This is a paranoid check and should be removed (not only here but
everywhere).

> +static int vsc73xx_port_vlan_prepare(struct dsa_switch *ds, int port,
> +				     const struct switchdev_obj_port_vlan *vlan)
> +{
> +	/* nothing needed */
> +	return 0;
> +}

Can you please rebase your work on top of the net-next/master branch?
You will see that the API has changed.
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git

> +
> +static void vsc73xx_port_vlan_add(struct dsa_switch *ds, int port,
> +				  const struct switchdev_obj_port_vlan *vlan)
> +{
> +	bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
> +	bool pvid = vlan->flags & BRIDGE_VLAN_INFO_PVID;
> +	struct vsc73xx *vsc = ds->priv;
> +	int ret;
> +	u32 tmp;
> +
> +	if (!dsa_port_is_vlan_filtering(dsa_to_port(ds, port)))
> +		return;

Sorry, but no. You need to support the case where the bridge (or 8021q
module) adds a VLAN even when the port is not enforcing VLAN filtering.
See commit:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=0ee2af4ebbe3c4364429859acd571018ebfb3424

> +
> +	ret = vsc73xx_port_update_vlan_table(ds, port, vlan->vid_begin,
> +					     vlan->vid_end, 1);
> +	if (ret)
> +		return;
> +
> +	if (untagged && port != CPU_PORT) {
> +		/* VSC73xx can have only one untagged vid per port. */
> +		vsc73xx_read(vsc, VSC73XX_BLOCK_MAC, port,
> +			     VSC73XX_TXUPDCFG, &tmp);
> +
> +		if (tmp & VSC73XX_TXUPDCFG_TX_UNTAGGED_VID_ENA)
> +			dev_warn(vsc->dev,
> +				 "Chip support only one untagged VID per port. Overwriting...\n");

Just return an error, don't overwrite, this leaves the bridge VLAN
information out of sync with the hardware otherwise, which is not a
great idea.

FWIW the drivers/net/dsa/ocelot/felix.c and drivers/net/mscc/ocelot.c
files support switching chips from the same vendor. The VSC73XX family
is much older, but some of the limitations apply to both architectures
nonetheless (like this one), you can surely borrow some ideas from
ocelot - in this case search for ocelot_vlan_prepare.

> +
> +		vsc73xx_update_bits(vsc, VSC73XX_BLOCK_MAC, port,
> +				    VSC73XX_TXUPDCFG,
> +				    VSC73XX_TXUPDCFG_TX_UNTAGGED_VID,
> +				    (vlan->vid_end <<
> +				    VSC73XX_TXUPDCFG_TX_UNTAGGED_VID_SHIFT) &
> +				    VSC73XX_TXUPDCFG_TX_UNTAGGED_VID);
> +		vsc73xx_update_bits(vsc, VSC73XX_BLOCK_MAC, port,
> +				    VSC73XX_TXUPDCFG,
> +				    VSC73XX_TXUPDCFG_TX_UNTAGGED_VID_ENA,
> +				    VSC73XX_TXUPDCFG_TX_UNTAGGED_VID_ENA);
> +	}
> +	if (pvid && port != CPU_PORT) {
> +		vsc73xx_update_bits(vsc, VSC73XX_BLOCK_MAC, port,
> +				    VSC73XX_CAT_DROP,
> +				    VSC73XX_CAT_DROP_UNTAGGED_ENA,
> +				    ~VSC73XX_CAT_DROP_UNTAGGED_ENA);
> +		vsc73xx_update_bits(vsc, VSC73XX_BLOCK_MAC, port,
> +				    VSC73XX_CAT_PORT_VLAN,
> +				    VSC73XX_CAT_PORT_VLAN_VLAN_VID,
> +				    vlan->vid_end &
> +				    VSC73XX_CAT_PORT_VLAN_VLAN_VID);
> +	}
> +}

  parent reply	other threads:[~2021-01-21 22:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20  6:30 [PATCH] dsa: vsc73xx: add support for vlan filtering Pawel Dembicki
2021-01-20 15:04 ` kernel test robot
2021-01-20 15:04   ` kernel test robot
2021-01-21 22:45 ` Vladimir Oltean [this message]
2021-01-24 23:19   ` Linus Walleij
2021-01-24 23:45     ` Vladimir Oltean
2021-01-25 13:25       ` Linus Walleij
2021-01-25  7:17   ` Paweł Dembicki
2021-01-28  0:37     ` Vladimir Oltean
2021-07-27 11:57       ` 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=20210121224505.nwfipzncw2h5d3rw@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=paweldembicki@gmail.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.