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
| ||
|
Message-ID: <ZVjLj6/iCL/muzmH@shell.armlinux.org.uk> Date: Sat, 18 Nov 2023 14:34:55 +0000 From: "Russell King (Oracle)" <linux@...linux.org.uk> To: Arınç ÜNAL <arinc.unal@...nc9.com> Cc: Daniel Golle <daniel@...rotopia.org>, Landen Chao <Landen.Chao@...iatek.com>, DENG Qingfang <dqfext@...il.com>, Sean Wang <sean.wang@...iatek.com>, Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, Vladimir Oltean <olteanv@...il.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Matthias Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org, Frank Wunderlich <frank-w@...lic-files.de>, Bartel Eerdekens <bartel.eerdekens@...stell8.be>, mithat.guner@...ont.com, erkin.bozoglu@...ont.com Subject: Re: [PATCH net-next 01/15] net: dsa: mt7530: always trap frames to active CPU port on MT7530 On Sat, Nov 18, 2023 at 03:31:51PM +0300, Arınç ÜNAL wrote: > + /* Set the CPU port to trap frames to for MT7530. Trapped frames will be > + * forwarded to the numerically smallest CPU port which the DSA conduit > + * interface its affine to is up. > + */ > + if (priv->id != ID_MT7530 && priv->id != ID_MT7621) > + return; > + > + if (operational) > + priv->active_cpu_ports |= BIT(cpu_dp->index); > + else > + priv->active_cpu_ports &= ~BIT(cpu_dp->index); > + > + if (priv->active_cpu_ports) > + mt7530_rmw(priv, MT7530_MFC, CPU_EN | CPU_PORT_MASK, CPU_EN | > + CPU_PORT(__ffs(priv->active_cpu_ports))); I would be tempted to write this as: mask = BIT(cpu_dp->index); if (operational) priv->active_cpu_ports |= mask; else priv->active_cpu_ports &= ~mask; Now, what happens when active_cpu_ports is zero? Doesn't that mean there is no active CPU port? In which case, wouldn't disabling the CPU port direction be appropriate, such as: if (priv->active_cpu_ports) val = CPU_EN | CPU_PORT(__ffs(priv->active_cpu_ports)); else val = 0; mt7530_rmw(priv, MT7530_MFC, CPU_EN | CPU_PORT_MASK, val); ? > struct mt7530_priv { > struct device *dev; > @@ -786,6 +787,7 @@ struct mt7530_priv { > struct irq_domain *irq_domain; > u32 irq_enable; > int (*create_sgmii)(struct mt7530_priv *priv, bool dual_sgmii); > + unsigned long active_cpu_ports; So this will be 32 or 64 bit in size. Presumably you know how many CPU ports there can be, which looking at this code must be less than 8 as CPU_PORT_MASK is only 3 bits in size. So, maybe use a u8, and check that cpu_dp->index <= 7 ? I would also suggest moving irq_enable after create_sgmii, to avoid holes in the struct. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists