From: David Laight <david.laight.linux@gmail.com>
To: "Arnd Bergmann" <arnd@arndb.de>
Cc: "Geert Uytterhoeven" <geert@linux-m68k.org>,
"Ping-Ke Shih" <pkshih@realtek.com>,
"rtl8821cerfe2@gmail.com" <rtl8821cerfe2@gmail.com>,
"kernel test robot" <lkp@intel.com>,
"oe-kbuild-all@lists.linux.dev" <oe-kbuild-all@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: include/linux/build_bug.h:78:41: error: static assertion failed: "sizeof(struct rtw8814a_efuse) == 512"
Date: Mon, 13 Apr 2026 14:01:09 +0100 [thread overview]
Message-ID: <20260413140109.2b20de7c@pumpkin> (raw)
In-Reply-To: <6b6310b8-2b0d-4390-992e-5ccd81cef2e0@app.fastmail.com>
On Mon, 13 Apr 2026 11:30:25 +0200
"Arnd Bergmann" <arnd@arndb.de> wrote:
> On Mon, Apr 13, 2026, at 11:15, Geert Uytterhoeven wrote:
> > On Mon, 13 Apr 2026 at 02:48, Ping-Ke Shih <pkshih@realtek.com> wrote:
> >> > On Fri, 10 Apr 2026 at 14:15, Ping-Ke Shih <pkshih@realtek.com> wrote:
> >> > How can that make a difference?
> >> > Both rtw8814au_efuse and rtw8814ae_efuse contain just (the same number
> >> > of) bytes, so __packed on the union should not make any difference?
> >> > Moreover, rtw8814au_efuse and rtw8814ae_efuse are already tagged with
> >> > __packed, which should also not make any difference. Someone's been
> >> > sprinkling too many __packed all over the place?
> >>
> >> I have similar thought as yours, but arm-linux-gnueabi-gcc compiler seems
> >> have special treatment with union. For this case, without __packed
> >> the offset of followed field res5 will become 0xe0.
> >
> > Hmm, I can confirm the original issue, and that adding __packed does
> > have an impact (it reduces the size of rtw8814a_efuse from 522 to 520),
> > but the actual size is still wrong (should be 512).
> >
> > drivers/net/wireless/realtek/rtw88/rtw88xxa.h has a similar issue, but
> > adding __packed does not make a difference there.
> >
> > Removing the __packed from struct rtw8814au_efuse increases its size
> > from 14 to 16 bytes. Looks like that ABI pads every structure to a
> > multiple of 4 bytes?
>
> Correct, that is a unique property of the ARM "OABI" legacy ABI,
> triggered by this defconfig line:
>
> # CONFIG_AEABI is not set
>
> Nobody should be using ARM OABI any more, and I think we should
> remove it from the kernel once support for the StrongARM
> CPU gets removed (I have patches for that), as those CPUs were
> the last ones that regularly used OABI.
That would definitely save all the annoyance of the otherwise
pointless __packed.
(I've seen it crop up before, but wasn't sure which architecture it was.)
Doesn't OABI also have 32bit bool?
> Annotating the union as '__packed' is the correct fix for
> the theoretical users of OABI, and does nothing on other
> supported targets in Linux.
The other option is to ensure the specific drivers aren't ever compiled
for !CONFIG_AEABI.
Then it'll all get tidied up when you remove it.
I read that the patches to remove 486 support have been merged.
I'm sure it would have made sense to drop everything before P-Pro
so that cmov can be used.
David
>
> Arnd
>
next prev parent reply other threads:[~2026-04-13 13:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-10 9:25 include/linux/build_bug.h:78:41: error: static assertion failed: "sizeof(struct rtw8814a_efuse) == 512" kernel test robot
2026-04-10 12:07 ` Bitterblue Smith
2026-04-10 12:14 ` Ping-Ke Shih
2026-04-11 15:29 ` Geert Uytterhoeven
2026-04-13 0:48 ` Ping-Ke Shih
2026-04-13 9:15 ` Geert Uytterhoeven
2026-04-13 9:30 ` Arnd Bergmann
2026-04-13 10:02 ` Geert Uytterhoeven
2026-04-13 13:01 ` David Laight [this message]
2026-04-13 13:46 ` Arnd Bergmann
2026-04-13 17:02 ` David Laight
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=20260413140109.2b20de7c@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=arnd@arndb.de \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=pkshih@realtek.com \
--cc=rtl8821cerfe2@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.