linux-kernel - Re: [PATCH net-next v2 3/8] net: dsa: lantiq

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: <20250819121126.y7jyc4xtvadnjemv@skbuf>
Date: Tue, 19 Aug 2025 15:11:26 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Hauke Mehrtens <hauke@...ke-m.de>, 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>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Russell King <linux@...linux.org.uk>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Andreas Schirm <andreas.schirm@...mens.com>,
	Lukas Stockmann <lukas.stockmann@...mens.com>,
	Alexander Sverdlin <alexander.sverdlin@...mens.com>,
	Peter Christen <peter.christen@...mens.com>,
	Avinash Jayaraman <ajayaraman@...linear.com>,
	Bing tao Xu <bxu@...linear.com>, Liang Xu <lxu@...linear.com>,
	Juraj Povazanec <jpovazanec@...linear.com>,
	"Fanni (Fang-Yi) Chan" <fchan@...linear.com>,
	"Benny (Ying-Tsan) Weng" <yweng@...linear.com>,
	"Livia M. Rosu" <lrosu@...linear.com>,
	John Crispin <john@...ozen.org>
Subject: Re: [PATCH net-next v2 3/8] net: dsa: lantiq_gswip: move definitions
 to header

On Tue, Aug 19, 2025 at 12:11:25PM +0100, Daniel Golle wrote:
> On Tue, Aug 19, 2025 at 01:50:55PM +0300, Vladimir Oltean wrote:
> > On Tue, Aug 19, 2025 at 02:33:02AM +0100, Daniel Golle wrote:
> > > +#define GSWIP_TABLE_ACTIVE_VLAN		0x01
> > > +#define GSWIP_TABLE_VLAN_MAPPING	0x02
> > > +#define GSWIP_TABLE_MAC_BRIDGE		0x0b
> > > +#define  GSWIP_TABLE_MAC_BRIDGE_KEY3_FID	GENMASK(5, 0)	/* Filtering identifier */
> > > +#define  GSWIP_TABLE_MAC_BRIDGE_VAL0_PORT	GENMASK(7, 4)	/* Port on learned entries */
> > > +#define  GSWIP_TABLE_MAC_BRIDGE_VAL1_STATIC	BIT(0)		/* Static, non-aging entry */
> > > +#define  GSWIP_TABLE_MAC_BRIDGE_VAL1_VALID	BIT(1)		/* Valid bit */
> > 
> > The VAL1_VALID bit definition sneaked in, there was no such thing in the
> > code being moved.
> > 
> > I'm willing to let this pass (I don't think I have other review comments
> > that would justify a resend), but it's not a good practice to introduce
> > changes in large quantities of code as you're moving them around.
> 
> I agree that this is bad and shouldn't have happened when moving the code.
> Already this makes git blame more difficult, so it should be as clean as
> possible, source and destination should match byte-by-byte.
> It happened because I had the fix for the gswip_port_fdb() (for which Vladimir
> is working on a better solution) sitting below the series and that added this
> bit.
> 
> I can resend just this single patch another time without the rest of the
> series, or send it all again. Let me know your preference.

I think in this case it's tolerable, because it's just a new macro, it
doesn't change the existing ones and doesn't result in changes to the
generated code. Not to mention it will probably have to be used - if you
saw it is used in Maxlinear's SDK drivers for newer switch IPs, then I
expect you will also need to set this bit, irrespective of my other
gswip_port_fdb() fix which just has to do with DSA API compliance.

At least I wouldn't push for the resend of an 8-patch set just because
of this. But it's a practice I would pay more attention to, in the
future, to avoid more serious things being modified.

If current-generation switches need the VAL1_VALID bit set, and are
broken without it, then the current arrangement would indeed be
problematic and I would advise to first fix that in 'net', wait for the
net -> net-next merge on Thursday to avoid conflicts, and then rebase
this patch on top. But I wasn't under the impression that VAL1_VALID is
needed for the IPs currently supported by the driver.