linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Prasanna Vengateshan <prasanna.vengateshan@microchip.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: <andrew@lunn.ch>, <netdev@vger.kernel.org>, <robh+dt@kernel.org>,
	<UNGLinuxDriver@microchip.com>, <Woojung.Huh@microchip.com>,
	<hkallweit1@gmail.com>, <linux@armlinux.org.uk>,
	<davem@davemloft.net>, <kuba@kernel.org>,
	<linux-kernel@vger.kernel.org>, <vivien.didelot@gmail.com>,
	<f.fainelli@gmail.com>, <devicetree@vger.kernel.org>
Subject: Re: [PATCH v4 net-next 10/10] net: dsa: microchip: add support for vlan operations
Date: Mon, 11 Oct 2021 23:13:36 +0530	[thread overview]
Message-ID: <6c97e0771204b492f31b3d003a5fd97d789920ef.camel@microchip.com> (raw)
In-Reply-To: <20211007201705.polwaqgbzff4u3vx@skbuf>

On Thu, 2021-10-07 at 23:17 +0300, Vladimir Oltean wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> > +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 ret;
> > +
> > +     ret = lan937x_cfg(dev, REG_SW_LUE_CTRL_0, SW_VLAN_ENABLE,
> > +                       flag);
> 
> If you're going to resend anyway, can you please check the entire
> submission for this pattern, where you can eliminate the intermediary
> "ret" variable and just return the function call directly?
> 
>         return lan937x_cfg(...)
Sure

> Do you have an explanation for what SW_VLAN_ENABLE does exactly?
Enabling the VLAN mode and then act as per the VLAN table.
Do you want me to add this explanation as a comment? or?



> > 
> > 
> > +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;
> > +     struct lan937x_vlan vlan_entry;
> > +     u16 pvid;
> > +     int ret;
> > +
> > +     lan937x_pread16(dev, port, REG_PORT_DEFAULT_VID, &pvid);
> > +     pvid &= 0xFFF;
> > +
> > +     ret = lan937x_get_vlan_table(dev, vlan->vid, &vlan_entry);
> > +     if (ret < 0) {
> > +             dev_err(dev->dev, "Failed to get vlan table\n");
> > +             return ret;
> > +     }
> > +     /* clear port fwd map */
> > +     vlan_entry.fwd_map &= ~BIT(port);
> > +
> > +     if (untagged)
> > +             vlan_entry.untag_prtmap &= ~BIT(port);
> 
> This is bogus.
> The user can add a VLAN entry using:
> 
> bridge vlan add dev lan0 vid 100 pvid untagged
> 
> and remove it using
> 
> bridge vlan del dev lan0 vid 100
> 
> so BRIDGE_VLAN_INFO_UNTAGGED is not set on removal.
> 
> Considering the fact that it doesn't matter whether the port is
> egress-tagged or not when it isn't in the fwd_map in the first place,
> I suggest you completely drop this condition.
Sure, i agree with you.

> 
> > +
> > +     ret = lan937x_set_vlan_table(dev, vlan->vid, &vlan_entry);
> > +     if (ret < 0) {
> > +             dev_err(dev->dev, "Failed to set vlan table\n");
> > +             return ret;
> > +     }
> > +
> > +     ret = lan937x_pwrite16(dev, port, REG_PORT_DEFAULT_VID, pvid);
> 
> What is the point of reading the pvid and writing it back unmodified?
> Is the AND-ing with 0xFFF supposed to do anything? Because when you
> write to REG_PORT_DEFAULT_VID, you write it with nothing in the upper
> bits, so I expect there to be nothing in the upper bits when you read it
> back either.
I had a feedback for not to reset the PVID as per the switchdev documentation
during vlan del. As part of the fix , i just removed PVID reset code alone but
missed these. Read/write PVID to be completely removed. I had a test case to
make sure that the PVID is not reset during vlan del. Since this is
reading/writing back the same values, could not catch them. I will clean up in
the next patch.


> 
> > +     if (ret < 0) {
> > +             dev_err(dev->dev, "Failed to set pvid\n");
> > +             return ret;
> > +     }
> > +
> > +     return 0;
> > +}
> 
> Also, consider the following set of commands:
> 
Step (0)
> ip link add br0 type bridge vlan_filtering 1
> ip link set lan0 master br0
> bridge vlan add dev lan0 vid 100 pvid untagged
Step (1)
> bridge vlan del dev lan0 vid 100
Step (2)
> ip link set br0 type bridge vlan_filtering 0
> 
> The expectation is that the switch, being VLAN-unaware as it is currently
> configured, receives and sends any packet regardless of VLAN ID.
> If you put an IP on br0 in this state, are you able to ping an outside host?

I have numbered the commands above.
Results are,
Before Step (0). Am able to ping outside.
After Step (0). Am not able to ping outside because the vlan table is set
After Step (1). Am not able to ping outside
After Step (2). Am able to ping outside because of vlan unaware mode.


  reply	other threads:[~2021-10-11 17:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-07 15:11 [PATCH v4 net-next 00/10] net: dsa: microchip: DSA driver support for LAN937x switch Prasanna Vengateshan
2021-10-07 15:11 ` [PATCH v4 net-next 01/10] dt-bindings: net: dsa: dt bindings for microchip lan937x Prasanna Vengateshan
2021-10-07 21:41   ` Andrew Lunn
2021-10-18 18:00     ` Rob Herring
2021-10-07 15:11 ` [PATCH v4 net-next 02/10] net: dsa: move mib->cnt_ptr reset code to ksz_common.c Prasanna Vengateshan
2021-10-07 15:11 ` [PATCH v4 net-next 03/10] net: phy: Add support for LAN937x T1 phy driver Prasanna Vengateshan
2021-10-07 15:11 ` [PATCH v4 net-next 04/10] net: dsa: tag_ksz: add tag handling for Microchip LAN937x Prasanna Vengateshan
2021-10-07 19:46   ` Vladimir Oltean
2021-10-07 15:11 ` [PATCH v4 net-next 05/10] net: dsa: microchip: add DSA support for microchip lan937x Prasanna Vengateshan
2021-10-07 20:00   ` Vladimir Oltean
2021-10-08 18:17     ` Prasanna Vengateshan
2021-10-07 21:58   ` Andrew Lunn
2021-10-07 15:11 ` [PATCH v4 net-next 06/10] net: dsa: microchip: add support for phylink management Prasanna Vengateshan
2021-10-07 15:11 ` [PATCH v4 net-next 07/10] net: dsa: microchip: add support for ethtool port counters Prasanna Vengateshan
2021-10-07 15:11 ` [PATCH v4 net-next 08/10] net: dsa: microchip: add support for port mirror operations Prasanna Vengateshan
2021-10-07 20:32   ` Vladimir Oltean
2021-10-07 15:11 ` [PATCH v4 net-next 09/10] net: dsa: microchip: add support for fdb and mdb management Prasanna Vengateshan
2021-10-07 20:29   ` Vladimir Oltean
2021-10-07 15:12 ` [PATCH v4 net-next 10/10] net: dsa: microchip: add support for vlan operations Prasanna Vengateshan
2021-10-07 20:17   ` Vladimir Oltean
2021-10-11 17:43     ` Prasanna Vengateshan [this message]
2021-10-14 14:19       ` 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=6c97e0771204b492f31b3d003a5fd97d789920ef.camel@microchip.com \
    --to=prasanna.vengateshan@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=Woojung.Huh@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=robh+dt@kernel.org \
    --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 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).