linux-kernel - Re: [PATCH net-next v9 3/3] net: dsa: yt921x: Add support for Motorcomm YT921x

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] [day] [month] [year] [list]

Message-ID: <CAAXyoMOpj1iCd6KZH0dQ-riuDSH_KOkvzB=cz66rWgykChda9g@mail.gmail.com>
Date: Thu, 18 Sep 2025 22:23:29 +0800
From: Yangfl <mmyangfl@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Simon Horman <horms@...nel.org>, Russell King <linux@...linux.org.uk>, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v9 3/3] net: dsa: yt921x: Add support for
 Motorcomm YT921x

On Wed, Sep 17, 2025 at 7:17 AM Vladimir Oltean <olteanv@...il.com> wrote:
...
> > +
> > +     mutex_lock(&priv->reg_lock);
> > +     res = yt921x_vlan_filtering(priv, port, vlan_filtering);
> > +     mutex_unlock(&priv->reg_lock);
> > +
> > +     return res;
> > +}
> > +
> > +static int
> > +yt921x_dsa_port_vlan_add(struct dsa_switch *ds, int port,
> > +                      const struct switchdev_obj_port_vlan *vlan,
> > +                      struct netlink_ext_ack *extack)
> > +{
> > +     struct yt921x_priv *priv = to_yt921x_priv(ds);
> > +     u16 vid = vlan->vid;
> > +     u16 pvid;
> > +     int res;
> > +
> > +     if ((priv->cpu_ports_mask & BIT(port)) != 0)
> > +             return 0;
>
> The CPU port is VLAN-unaware by default and the driver leaves it that
> way, correct?
>

Yes. Actually flows via CPU port are entirely up to the tag, and we
actively isolate it from any other ports (see port_setup()) so packets
without tag are automatically dropped.

...
>
> > +static int yt921x_chip_setup(struct yt921x_priv *priv)
> > +{
> > +     struct dsa_switch *ds = &priv->ds;
> > +     unsigned long cpu_ports_mask;
> > +     u64 ctrl64;
> > +     u32 ctrl;
> > +     int port;
> > +     int res;
> > +
> > +     /* Enable DSA */
> > +     priv->cpu_ports_mask = dsa_cpu_ports(ds);
> > +
> > +     ctrl = YT921X_EXT_CPU_PORT_TAG_EN | YT921X_EXT_CPU_PORT_PORT_EN |
> > +            YT921X_EXT_CPU_PORT_PORT(__ffs(priv->cpu_ports_mask));
> > +     res = yt921x_reg_write(priv, YT921X_EXT_CPU_PORT, ctrl);
> > +     if (res)
> > +             return res;
> > +
> > +     /* Enable and clear MIB */
> > +     res = yt921x_reg_set_bits(priv, YT921X_FUNC, YT921X_FUNC_MIB);
> > +     if (res)
> > +             return res;
> > +
> > +     ctrl = YT921X_MIB_CTRL_CLEAN | YT921X_MIB_CTRL_ALL_PORT;
> > +     res = yt921x_reg_write(priv, YT921X_MIB_CTRL, ctrl);
> > +     if (res)
> > +             return res;
> > +
> > +     /* Setup software switch */
> > +     ctrl = YT921X_CPU_COPY_TO_EXT_CPU;
> > +     res = yt921x_reg_write(priv, YT921X_CPU_COPY, ctrl);
> > +     if (res)
> > +             return res;
> > +
> > +     ctrl = GENMASK(10, 0);
> > +     res = yt921x_reg_write(priv, YT921X_FILTER_UNK_UCAST, ctrl);
> > +     if (res)
> > +             return res;
> > +     res = yt921x_reg_write(priv, YT921X_FILTER_UNK_MCAST, ctrl);
> > +     if (res)
> > +             return res;
> > +
> > +     /* YT921x does not support native DSA port bridging, so we use port
> > +      * isolation to emulate it. However, be especially careful that port
> > +      * isolation takes _after_ FDB lookups, i.e. if an FDB entry (from
> > +      * another bridge) is matched and the destination port (in another
> > +      * bridge) is blocked, the packet will be dropped instead of flooding to
> > +      * the "bridged" ports, thus we need to handle those packets by
> > +      * software.
> > +      *
> > +      * If there is no more than one bridge, we might be able to drop them
> > +      * directly given some conditions are met, but for now we trap them in
> > +      * all cases.
> > +      */
> > +     ctrl = 0;
> > +     for (int i = 0; i < YT921X_PORT_NUM; i++)
> > +             ctrl |= YT921X_ACT_UNK_ACTn_TRAP(i);
>
> YT921X_ACT_UNK_ACTn_TRAP traps packets with FDB misses to the CPU, correct?

Yes, and

> How does that address the described problem, where an FDB entry is
> found, but the destination port is isolated from the source?

also in this case.

...