Re: [PATCH RFC net-next 06/23] net: dsa: lantiq_gswip: load model-specific microcode

[Daniel Golle <daniel@makrotopia.org>]

On Sun, Aug 17, 2025 at 05:29:16PM +0200, Andrew Lunn wrote:
> >  
> > +struct gswip_pce_microcode {
> > +	u16 val_3;
> > +	u16 val_2;
> > +	u16 val_1;
> > +	u16 val_0;
> > +};
> > +
> 
> I would leave this where it is, and just have
> 
> struct gswip_pce_microcode;
> 
> Since only a pointer is needed, the compiler does not need the full
> type info, at this point.
> 
> The structure itself is rather opaque, and only makes some sort of
> sense when next to the MAC_ENTRY macro.

The structure is also used in the function gswip_pce_load_microcode().
Now, if we keep defining the struct fields along with the microcode this
will become a problem once there is more than one such set of microcode
instructions and additional header files for them. Each of them would
need to define struct gswip_pce_microcode with its fields.
The lantiq_pce.h header then becomes private to the driver for the
in-SoC switches, while gswip_pce_load_microcode() would be part of the
shared/common module use by both, in-SoC/MMIO switches as well as
(newer) MDIO-connected ones, and I would not want to include any of the
*_pce.h headers in the shared/common module.

Obviously I can just move the struct definition in the later commit
which actually separates the MMIO-specific parts of the driver and the
common/shared parts into different modules. Is it that what you had in
mind?