netdev - Re: [PATCH net-next v2 3/6] net: dsa: lantiq: allow arbitrary MII registers

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

Message-ID: <20260115100655.da2w3zsxmi3ze5rz@skbuf>
Date: Thu, 15 Jan 2026 12:06:55 +0200
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>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Chen Minqiang <ptpt52@...il.com>,
	Xinfa Deng <xinfa.deng@...inet.com>
Subject: Re: [PATCH net-next v2 3/6] net: dsa: lantiq: allow arbitrary MII
 registers

On Thu, Jan 15, 2026 at 01:40:50AM +0000, Daniel Golle wrote:
> On Thu, Jan 15, 2026 at 12:57:07AM +0000, Daniel Golle wrote:
> > The Lantiq GSWIP and MaxLinear GSW1xx drivers are currently relying on a
> > hard-coded mapping of MII ports to their respective MII_CFG and MII_PCDU
> > registers and only allow applying an offset to the port index.
> > 
> > While this is sufficient for the currently supported hardware, the very
> > similar Intel GSW150 (aka. Lantiq PEB7084) cannot be described using
> > this arrangement.
> > 
> > Introduce two arrays to specify the MII_CFG and MII_PCDU registers for
> > each port, replacing the current bitmap used to safeguard MII ports as
> > well as the port index offset.
> > 
> > Signed-off-by: Daniel Golle <daniel@...rotopia.org>
> > ---
> > v2:
> >  * introduce GSWIP_MAX_PORTS macro
> > 
> >  drivers/net/dsa/lantiq/lantiq_gswip.c        | 30 ++++++++++++++++----
> >  drivers/net/dsa/lantiq/lantiq_gswip.h        |  6 ++--
> >  drivers/net/dsa/lantiq/lantiq_gswip_common.c | 27 +++---------------
> >  drivers/net/dsa/lantiq/mxl-gsw1xx.c          | 30 ++++++++++++++++----
> >  4 files changed, 56 insertions(+), 37 deletions(-)
> > 
> > diff --git a/drivers/net/dsa/lantiq/lantiq_gswip.c b/drivers/net/dsa/lantiq/lantiq_gswip.c
> > index b094001a7c805..4a1be6a1df6fe 100644
> > --- a/drivers/net/dsa/lantiq/lantiq_gswip.c
> > +++ b/drivers/net/dsa/lantiq/lantiq_gswip.c
> > @@ -463,10 +463,20 @@ static void gswip_shutdown(struct platform_device *pdev)
> >  }
> >  
> >  static const struct gswip_hw_info gswip_xrx200 = {
> > -	.max_ports = 7,
> > +	.max_ports = GSWIP_MAX_PORTS,
> >  	.allowed_cpu_ports = BIT(6),
> > -	.mii_ports = BIT(0) | BIT(1) | BIT(5),
> > -	.mii_port_reg_offset = 0,
> > +	.mii_cfg = {
> > +		[0 ... GSWIP_MAX_PORTS - 1] = -1,
> > +		[0] = GSWIP_MII_CFGp(0),
> > +		[1] = GSWIP_MII_CFGp(1),
> > +		[5] = GSWIP_MII_CFGp(5),
> > +	},
> 
> Kernel CI trips with
> warning: initialized field overwritten [-Woverride-init]
> 
> Would it be ok to enclose the gswip_hw_info initializers with
> __diag_push();
> __diag_ignore_all("-Woverride-init",
> 		  "logic to initialize all and then override some is OK");
> 
> like it is done in drivers/net/ethernet/renesas/sh_eth.c?
> 
> Or should I rather keep the .mii_ports bitmap in addition to the array
> to indicate the indexes with valid values?

This is new syntax for me. I don't have an issue either way. It seems
netdev maintainers did already accept it for another Ethernet driver, so
I suppose you could go with __diag_ignore_all().

FWIW, when I had to handle similar things, I opted for the simpler
"spell them out one by one" approach, see sja1110_regs in
drivers/net/dsa/sja1105/sja1105_spi.c. But that shouldn't necessarily be
the only way.