public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: <Arun.Ramadoss@microchip.com>
To: <olteanv@gmail.com>
Cc: <andrew@lunn.ch>, <linux-kernel@vger.kernel.org>,
	<UNGLinuxDriver@microchip.com>, <vivien.didelot@gmail.com>,
	<linux@armlinux.org.uk>, <f.fainelli@gmail.com>,
	<kuba@kernel.org>, <edumazet@google.com>, <pabeni@redhat.com>,
	<netdev@vger.kernel.org>, <Woojung.Huh@microchip.com>,
	<davem@davemloft.net>
Subject: Re: [Patch RFC net-next 4/4] net: dsa: microchip: use private pvid for bridge_vlan_unwaware
Date: Tue, 2 Aug 2022 14:40:09 +0000	[thread overview]
Message-ID: <365b35f48b4a6c2003b67a4ee0c287b8172fa262.camel@microchip.com> (raw)
In-Reply-To: <20220802105935.gjjc3ft6zf35xrhr@skbuf>

On Tue, 2022-08-02 at 13:59 +0300, Vladimir Oltean wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> On Fri, Jul 29, 2022 at 08:47:33PM +0530, Arun Ramadoss wrote:
> > diff --git a/drivers/net/dsa/microchip/ksz_common.c
> > b/drivers/net/dsa/microchip/ksz_common.c
> > index 516fb9d35c87..8a5583b1f2f4 100644
> > --- a/drivers/net/dsa/microchip/ksz_common.c
> > +++ b/drivers/net/dsa/microchip/ksz_common.c
> > @@ -161,6 +161,7 @@ static const struct ksz_dev_ops ksz8_dev_ops =
> > {
> >       .vlan_filtering = ksz8_port_vlan_filtering,
> >       .vlan_add = ksz8_port_vlan_add,
> >       .vlan_del = ksz8_port_vlan_del,
> > +     .drop_untagged = ksz8_port_enable_pvid,
> 
> You'll have to explain this one. What impact does PVID insertion on
> KSZ8
> have upon dropping/not dropping untagged packets? This patch is
> saying
> that when untagged packets should be dropped, PVID insertion should
> be
> enabled, and when untagged packets should be accepted, PVID insertion
> should be disabled. How come?

Its my mistake. I referred KSZ87xx datasheet but I couldn't find the
register for the dropping the untagged packet. If that is the case,
shall I remove the dropping of untagged packet feature from the ksz8
switches?

> 
> >       .mirror_add = ksz8_port_mirror_add,
> >       .mirror_del = ksz8_port_mirror_del,
> >       .get_caps = ksz8_get_caps,
> > @@ -187,6 +188,7 @@ static const struct ksz_dev_ops ksz9477_dev_ops
> > = {
> >       .vlan_filtering = ksz9477_port_vlan_filtering,
> >       .vlan_add = ksz9477_port_vlan_add,
> >       .vlan_del = ksz9477_port_vlan_del,
> > +     .drop_untagged = ksz9477_port_drop_untagged,
> >       .mirror_add = ksz9477_port_mirror_add,
> >       .mirror_del = ksz9477_port_mirror_del,
> >       .get_caps = ksz9477_get_caps,
> > @@ -220,6 +222,7 @@ static const struct ksz_dev_ops lan937x_dev_ops
> > = {
> >       .vlan_filtering = ksz9477_port_vlan_filtering,
> >       .vlan_add = ksz9477_port_vlan_add,
> >       .vlan_del = ksz9477_port_vlan_del,
> > +     .drop_untagged = ksz9477_port_drop_untagged,
> >       .mirror_add = ksz9477_port_mirror_add,
> >       .mirror_del = ksz9477_port_mirror_del,
> >       .get_caps = lan937x_phylink_get_caps,
> > @@ -1254,6 +1257,9 @@ static int ksz_enable_port(struct dsa_switch
> > *ds, int port,
> >  {
> >       struct ksz_device *dev = ds->priv;
> > 
> > +     dev->dev_ops->vlan_add(dev, port, KSZ_DEFAULT_VLAN,
> > +                            BRIDGE_VLAN_INFO_UNTAGGED);
> > +
> 
> How many times can this be executed before the VLAN add operation
> fails
> due to the VLAN already being present on the port? I notice you're
> ignoring the return code. Wouldn't it be better to do this at
> port_setup() time instead?
> 
> (side note, the PVID for standalone mode can be added at port_setup
> time. The PVID to use for bridges in VLAN-unaware mode can be
> allocated
> at port_bridge_join time)

Ok. I will add in port_bridge_join function for bridge vlan_aware
ports.

> 
> >       if (!dsa_is_user_port(ds, port))
> >               return 0;
> > 
> > +static int ksz_commit_pvid(struct dsa_switch *ds, int port)
> > +{
> > +     struct dsa_port *dp = dsa_to_port(ds, port);
> > +     struct net_device *br = dsa_port_bridge_dev_get(dp);
> > +     struct ksz_device *dev = ds->priv;
> > +     u16 pvid = KSZ_DEFAULT_VLAN;
> > +     bool drop_untagged = false;
> > +     struct ksz_port *p;
> > +
> > +     p = &dev->ports[port];
> > +
> > +     if (br && br_vlan_enabled(br)) {
> > +             pvid = p->bridge_pvid.vid;
> > +             drop_untagged = !p->bridge_pvid.valid;
> > +     }
> 
> This is better in the sense that it resolves the need for the
> configure_vlan_while_not_filtering hack. But standalone and VLAN-
> unaware
> bridge ports still share the same PVID. Even more so, standalone
> ports
> have address learning enabled, which will poison the address database
> of
> VLAN-unaware bridge ports (and of other standalone ports):
> 
https://patchwork.kernel.org/project/netdevbpf/patch/20220802002636.3963025-1-vladimir.oltean@nxp.com/
> 
> Are you going to do further work in this area?

For now, I thought I can fix the issue for bridge vlan unaware port. I
have few other patch series to be submitted like gPTP, tc commands. If
standalone port fix also needed for your patch series I can work on it
otherwise I can take up later stage.


> 
> > +
> > +     ksz_set_pvid(dev, port, pvid);
> > +
> > +     if (dev->dev_ops->drop_untagged)
> > +             dev->dev_ops->drop_untagged(dev, port,
> > drop_untagged);
> > +
> > +     return 0;
> > +}

  reply	other threads:[~2022-08-02 14:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29 15:17 [Patch RFC net-next 0/4] net: dsa: microchip: vlan configuration for bridge_vlan_unaware ports Arun Ramadoss
2022-07-29 15:17 ` [Patch RFC net-next 1/4] net: dsa: microchip: modify vlan_add function prototype Arun Ramadoss
2022-08-02 10:32   ` Vladimir Oltean
2022-08-02 13:58     ` Arun.Ramadoss
2022-07-29 15:17 ` [Patch RFC net-next 2/4] net: dsa: microchip: lan937x: remove vlan_filtering_is_global flag Arun Ramadoss
2022-08-02 10:40   ` Vladimir Oltean
2022-08-02 16:09     ` Arun.Ramadoss
2022-08-03 11:07       ` Vladimir Oltean
2022-07-29 15:17 ` [Patch RFC net-next 3/4] net: dsa: microchip: common ksz pvid get and set function Arun Ramadoss
2022-08-02 10:45   ` Vladimir Oltean
2022-08-04  2:05   ` Florian Fainelli
2022-07-29 15:17 ` [Patch RFC net-next 4/4] net: dsa: microchip: use private pvid for bridge_vlan_unwaware Arun Ramadoss
2022-08-02 10:59   ` Vladimir Oltean
2022-08-02 14:40     ` Arun.Ramadoss [this message]
2022-08-03 14:49       ` 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=365b35f48b4a6c2003b67a4ee0c287b8172fa262.camel@microchip.com \
    --to=arun.ramadoss@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=Woojung.Huh@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@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=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox