From: Daniel Golle <daniel@makrotopia.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Hauke Mehrtens <hauke@hauke-m.de>,
Simon Horman <horms@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Florian Fainelli <f.fainelli@gmail.com>,
Arkadi Sharshevsky <arkadis@mellanox.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Andreas Schirm <andreas.schirm@siemens.com>,
Lukas Stockmann <lukas.stockmann@siemens.com>,
Alexander Sverdlin <alexander.sverdlin@siemens.com>,
Peter Christen <peter.christen@siemens.com>,
Avinash Jayaraman <ajayaraman@maxlinear.com>,
Bing tao Xu <bxu@maxlinear.com>, Liang Xu <lxu@maxlinear.com>,
Juraj Povazanec <jpovazanec@maxlinear.com>,
"Fanni (Fang-Yi) Chan" <fchan@maxlinear.com>,
"Benny (Ying-Tsan) Weng" <yweng@maxlinear.com>,
"Livia M. Rosu" <lrosu@maxlinear.com>,
John Crispin <john@phrozen.org>
Subject: Re: [PATCH RFC net-next 06/23] net: dsa: lantiq_gswip: load model-specific microcode
Date: Tue, 19 Aug 2025 01:44:27 +0100 [thread overview]
Message-ID: <aKPI6xMIgIeBzqy7@pidgin.makrotopia.org> (raw)
In-Reply-To: <aKI_t6F0zzLq2AMw@pidgin.makrotopia.org>
On Sun, Aug 17, 2025 at 09:46:51PM +0100, Daniel Golle wrote:
> 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?
I didn't consider that the size of the array elements needs to be known
when defining struct gswip_hw_info in lantiq_gswip.h.
So the only reasonable solution is to make also the definition of
struct gswip_pce_microcode into lantiq_gswip.h, so lantiq_pce.h won't
have to be included before or by lantiq_gswip.h itself.
In file included from drivers/net/dsa/lantiq_gswip.c:28:
drivers/net/dsa/lantiq_gswip.h:226:44: error: array type has incomplete element type 'struct gswip_pce_microcode'
226 | const struct gswip_pce_microcode (*pce_microcode)[];
| ^~~~~~~~~~~~~
next prev parent reply other threads:[~2025-08-19 0:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-16 19:52 [PATCH RFC net-next 06/23] net: dsa: lantiq_gswip: load model-specific microcode Daniel Golle
2025-08-17 15:29 ` Andrew Lunn
2025-08-17 20:46 ` Daniel Golle
2025-08-19 0:44 ` Daniel Golle [this message]
2025-08-19 13:17 ` Andrew Lunn
2025-08-19 14:07 ` Daniel Golle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aKPI6xMIgIeBzqy7@pidgin.makrotopia.org \
--to=daniel@makrotopia.org \
--cc=ajayaraman@maxlinear.com \
--cc=alexander.sverdlin@siemens.com \
--cc=andreas.schirm@siemens.com \
--cc=andrew@lunn.ch \
--cc=arkadis@mellanox.com \
--cc=bxu@maxlinear.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=fchan@maxlinear.com \
--cc=hauke@hauke-m.de \
--cc=horms@kernel.org \
--cc=john@phrozen.org \
--cc=jpovazanec@maxlinear.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lrosu@maxlinear.com \
--cc=lukas.stockmann@siemens.com \
--cc=lxu@maxlinear.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=peter.christen@siemens.com \
--cc=yweng@maxlinear.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).