lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210422190351.qdv2xlnxghmfpjqj@skbuf>
Date:   Thu, 22 Apr 2021 22:03:51 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Prasanna Vengateshan <prasanna.vengateshan@...rochip.com>
Cc:     andrew@...n.ch, netdev@...r.kernel.org, robh+dt@...nel.org,
        UNGLinuxDriver@...rochip.com, hkallweit1@...il.com,
        linux@...linux.org.uk, davem@...emloft.net, kuba@...nel.org,
        linux-kernel@...r.kernel.org, vivien.didelot@...il.com,
        f.fainelli@...il.com, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 net-next 9/9] net: dsa: microchip: add support for
 vlan operations

On Thu, Apr 22, 2021 at 03:12:57PM +0530, Prasanna Vengateshan wrote:
> Support for VLAN add, del, prepare and filtering operations.
> 
> It aligns with latest update of removing switchdev
> transactional logic from VLAN objects

Maybe more in the commit message about what the patch does, as opposed
to mentioning that you had to rebase it, would be helpful.

> 
> Signed-off-by: Prasanna Vengateshan <prasanna.vengateshan@...rochip.com>
> ---
>  drivers/net/dsa/microchip/lan937x_main.c | 214 +++++++++++++++++++++++
>  1 file changed, 214 insertions(+)
> 
> diff --git a/drivers/net/dsa/microchip/lan937x_main.c b/drivers/net/dsa/microchip/lan937x_main.c
> index 7f6183dc0e31..35f3456c3506 100644
> --- a/drivers/net/dsa/microchip/lan937x_main.c
> +++ b/drivers/net/dsa/microchip/lan937x_main.c
> @@ -14,6 +14,103 @@
>  #include "ksz_common.h"
>  #include "lan937x_dev.h"
>  
> +static int lan937x_wait_vlan_ctrl_ready(struct ksz_device *dev)
> +{
> +	unsigned int val;
> +
> +	return regmap_read_poll_timeout(dev->regmap[0], REG_SW_VLAN_CTRL,
> +					val, !(val & VLAN_START), 10, 1000);
> +}
> +
> +static int lan937x_get_vlan_table(struct ksz_device *dev, u16 vid,
> +				  u32 *vlan_table)
> +{
> +	int rc;
> +
> +	mutex_lock(&dev->vlan_mutex);
> +
> +	rc = ksz_write16(dev, REG_SW_VLAN_ENTRY_INDEX__2, vid & VLAN_INDEX_M);
> +	if (rc < 0)
> +		goto exit;
> +
> +	rc = ksz_write8(dev, REG_SW_VLAN_CTRL, VLAN_READ | VLAN_START);
> +	if (rc < 0)
> +		goto exit;
> +
> +	/* wait to be cleared */
> +	rc = lan937x_wait_vlan_ctrl_ready(dev);
> +	if (rc < 0)
> +		goto exit;
> +
> +	rc = ksz_read32(dev, REG_SW_VLAN_ENTRY__4, &vlan_table[0]);
> +	if (rc < 0)
> +		goto exit;
> +
> +	rc = ksz_read32(dev, REG_SW_VLAN_ENTRY_UNTAG__4, &vlan_table[1]);
> +	if (rc < 0)
> +		goto exit;
> +
> +	rc = ksz_read32(dev, REG_SW_VLAN_ENTRY_PORTS__4, &vlan_table[2]);
> +	if (rc < 0)
> +		goto exit;
> +
> +	rc = ksz_write8(dev, REG_SW_VLAN_CTRL, 0);
> +	if (rc < 0)
> +		goto exit;
> +
> +exit:
> +	mutex_unlock(&dev->vlan_mutex);
> +
> +	return rc;
> +}
> +
> +static int lan937x_set_vlan_table(struct ksz_device *dev, u16 vid,
> +				  u32 *vlan_table)
> +{
> +	int rc;
> +
> +	mutex_lock(&dev->vlan_mutex);
> +
> +	rc = ksz_write32(dev, REG_SW_VLAN_ENTRY__4, vlan_table[0]);
> +	if (rc < 0)
> +		goto exit;
> +
> +	rc = ksz_write32(dev, REG_SW_VLAN_ENTRY_UNTAG__4, vlan_table[1]);
> +	if (rc < 0)
> +		goto exit;
> +
> +	rc = ksz_write32(dev, REG_SW_VLAN_ENTRY_PORTS__4, vlan_table[2]);
> +	if (rc < 0)
> +		goto exit;
> +
> +	rc = ksz_write16(dev, REG_SW_VLAN_ENTRY_INDEX__2, vid & VLAN_INDEX_M);
> +	if (rc < 0)
> +		goto exit;
> +
> +	rc = ksz_write8(dev, REG_SW_VLAN_CTRL, VLAN_START | VLAN_WRITE);
> +	if (rc < 0)
> +		goto exit;
> +
> +	/* wait to be cleared */
> +	rc = lan937x_wait_vlan_ctrl_ready(dev);
> +	if (rc < 0)
> +		goto exit;
> +
> +	rc = ksz_write8(dev, REG_SW_VLAN_CTRL, 0);
> +	if (rc < 0)
> +		goto exit;
> +
> +	/* update vlan cache table */
> +	dev->vlan_cache[vid].table[0] = vlan_table[0];
> +	dev->vlan_cache[vid].table[1] = vlan_table[1];
> +	dev->vlan_cache[vid].table[2] = vlan_table[2];
> +
> +exit:
> +	mutex_unlock(&dev->vlan_mutex);
> +
> +	return rc;
> +}
> +
>  static int lan937x_read_table(struct ksz_device *dev, u32 *table)
>  {
>  	int rc;
> @@ -190,6 +287,120 @@ static void lan937x_port_stp_state_set(struct dsa_switch *ds, int port,
>  	mutex_unlock(&dev->dev_mutex);
>  }
>  
> +static int lan937x_port_vlan_filtering(struct dsa_switch *ds, int port,
> +				       bool flag,
> +				       struct netlink_ext_ack *extack)
> +{
> +	struct ksz_device *dev = ds->priv;
> +	int rc;
> +
> +	if (flag) {
> +		rc = lan937x_port_cfg(dev, port, REG_PORT_LUE_CTRL,
> +				      PORT_VLAN_LOOKUP_VID_0, true);
> +		if (rc < 0)
> +			return rc;

What does this bit do?

> +
> +		rc = lan937x_cfg(dev, REG_SW_LUE_CTRL_0, SW_VLAN_ENABLE, true);

How about this bit?

I see one bit is per port and the other is global.
Just FYI, you can have this configuration:

ip link add br0 type bridge vlan_filtering 0
ip link add br1 type bridge vlan_filtering 1
ip link set swp0 master br0
ip link set swp1 master br0
ip link set swp2 master br1
ip link set swp3 master br1

Do the swp0 and swp1 ports remain VLAN-unaware after you touch this
REG_SW_LUE_CTRL_0 bit?

> +	} else {
> +		rc = lan937x_cfg(dev, REG_SW_LUE_CTRL_0, SW_VLAN_ENABLE, false);
> +		if (rc < 0)
> +			return rc;
> +
> +		rc = lan937x_port_cfg(dev, port, REG_PORT_LUE_CTRL,
> +				      PORT_VLAN_LOOKUP_VID_0, false);
> +	}
> +
> +	return rc;
> +}
> +
> +static int lan937x_port_vlan_add(struct dsa_switch *ds, int port,
> +				 const struct switchdev_obj_port_vlan *vlan,
> +				 struct netlink_ext_ack *extack)
> +{
> +	bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
> +	struct ksz_device *dev = ds->priv;
> +	u32 vlan_table[3];

Maybe a structure would be nicer to read than an u32 array?

> +	int rc;
> +
> +	rc = lan937x_get_vlan_table(dev, vlan->vid, vlan_table);
> +	if (rc < 0) {
> +		dev_err(dev->dev, "Failed to get vlan table\n");

One of the reasons for which the extack exists is so that you can report
errors to user space and not to the console.

		NL_SET_ERR_MSG_MOD(extack, "Failed to get vlan table");

> +		return rc;
> +	}
> +
> +	vlan_table[0] = VLAN_VALID | (vlan->vid & VLAN_FID_M);
> +
> +	/* set/clear switch port when updating vlan table registers */
> +	if (untagged)
> +		vlan_table[1] |= BIT(port);
> +	else
> +		vlan_table[1] &= ~BIT(port);
> +	vlan_table[1] &= ~(BIT(dev->cpu_port));
> +
> +	vlan_table[2] |= BIT(port) | BIT(dev->cpu_port);

What's the business with the CPU port here? Does DSA not call
.port_vlan_add for the CPU port separately?

> +
> +	rc = lan937x_set_vlan_table(dev, vlan->vid, vlan_table);
> +	if (rc < 0) {
> +		dev_err(dev->dev, "Failed to set vlan table\n");
> +		return rc;
> +	}
> +
> +	/* change PVID */
> +	if (vlan->flags & BRIDGE_VLAN_INFO_PVID) {
> +		rc = lan937x_pwrite16(dev, port, REG_PORT_DEFAULT_VID, vlan->vid);
> +
> +		if (rc < 0) {
> +			dev_err(dev->dev, "Failed to set pvid\n");
> +			return rc;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static int lan937x_port_vlan_del(struct dsa_switch *ds, int port,
> +				 const struct switchdev_obj_port_vlan *vlan)
> +{
> +	bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
> +	struct ksz_device *dev = ds->priv;
> +	u32 vlan_table[3];
> +	u16 pvid;
> +	int rc;
> +
> +	lan937x_pread16(dev, port, REG_PORT_DEFAULT_VID, &pvid);
> +	pvid &= 0xFFF;
> +
> +	rc = lan937x_get_vlan_table(dev, vlan->vid, vlan_table);
> +
> +	if (rc < 0) {
> +		dev_err(dev->dev, "Failed to get vlan table\n");
> +		return rc;
> +	}
> +	/* clear switch port number */
> +	vlan_table[2] &= ~BIT(port);
> +
> +	if (pvid == vlan->vid)
> +		pvid = 1;

According to Documentation/networking/switchdev.rst:

When the bridge has VLAN filtering enabled and a PVID is not configured on the
ingress port, untagged and 802.1p tagged packets must be dropped. When the bridge
has VLAN filtering enabled and a PVID exists on the ingress port, untagged and
priority-tagged packets must be accepted and forwarded according to the
bridge's port membership of the PVID VLAN. When the bridge has VLAN filtering
disabled, the presence/lack of a PVID should not influence the packet
forwarding decision.

So please don't reset the pvid.

> +
> +	if (untagged)
> +		vlan_table[1] &= ~BIT(port);
> +
> +	rc = lan937x_set_vlan_table(dev, vlan->vid, vlan_table);
> +	if (rc < 0) {
> +		dev_err(dev->dev, "Failed to set vlan table\n");
> +		return rc;
> +	}
> +
> +	rc = lan937x_pwrite16(dev, port, REG_PORT_DEFAULT_VID, pvid);
> +
> +	if (rc < 0) {
> +		dev_err(dev->dev, "Failed to set pvid\n");
> +		return rc;
> +	}
> +
> +	return 0;
> +}
> +
>  static u8 lan937x_get_fid(u16 vid)
>  {
>  	if (vid > ALU_FID_SIZE)
> @@ -955,6 +1166,9 @@ const struct dsa_switch_ops lan937x_switch_ops = {
>  	.port_bridge_flags	= lan937x_port_bridge_flags,
>  	.port_stp_state_set	= lan937x_port_stp_state_set,
>  	.port_fast_age		= ksz_port_fast_age,
> +	.port_vlan_filtering	= lan937x_port_vlan_filtering,
> +	.port_vlan_add		= lan937x_port_vlan_add,
> +	.port_vlan_del		= lan937x_port_vlan_del,
>  	.port_fdb_dump		= lan937x_port_fdb_dump,
>  	.port_fdb_add		= lan937x_port_fdb_add,
>  	.port_fdb_del		= lan937x_port_fdb_del,
> -- 
> 2.27.0
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ