Re: [PATCH net-next v2 3/8] net: dsa: lantiq_gswip: move definitions to header

[Vladimir Oltean <olteanv@gmail.com>]

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.