Couple of clang warnings for Rockchip boards

[Tom Rini]

On Thu, Apr 23, 2026 at 12:24:13PM +0200, Quentin Schulz wrote:
> Hi Simon,
> 
> On 4/22/26 11:57 PM, Simon Glass wrote:
> > Hi Quentin,
> > 
> > On Thu, 23 Apr 2026 at 01:26, Quentin Schulz <quentin.schulz at cherry.de> wrote:
> > > 
> > > Hi all,
> > > 
> > > I'm looking into force-enabling CONFIG_WERROR for all Rockchip SoCs.
> > > First, let me know if this is a bad idea :)
> > 
> > I don't like it, as it makes development slower. I like to see all the
> > warnings created by a change and tend to fix them iteratively. We
> > already have a warning check in CI. A better approach is to
> > 
> > Can you use: KCFLAGS=-Werror
> > 
> > either in your environment or on the 'make' cmdline?
> > 
> 
> Well, if it's during development, you can always disable WERROR? The fact
> that I've never actually enabled -Werror locally in about a decade in U-Boot
> probably isn't a good sign. One of the things that make me wary though is
> compiler updates with new warnings. I've tested with clang 22, don't know
> when clang 23 is planned to be released. GCC 16 is about to be released as
> well.

Personally, I think -Werror being a pro or a con during development is
up to the developer. I'm very much a "turn this on, fail the build when
I transpose arguments, etc" kind of developer.

> By having the check in CI, we have a longer-than-necessary feedback loop for
> contributors. Has this been an issue in the past? /me shrugs

Yes, a not uncommon occurrence is patches, or even PRs, having to be
respun because of "variable unused" warnings. Which having typed that is
more likely what bothers Simon's flow.

> No defconfig seems to be setting this option, not sure exactly why that is.
> 
> Also, FYI, enabling CONFIG_WERROR doesn't apply the -Werror flag to the host
> tools, which I believe is an oversight. I see buildman sets
> HOSTCFLAGS=-Werror, maybe we should do that in the appropriate place based
> on CONFIG_WERROR as well?

What does the linux kernel do here? We're just borrowing logic again.

[snip]
> So, looking a bit more into this, the kernel actually silences a bunch of
> warnings when not passing W=N to `make`, one of them being unaligned-access,
> see https://elixir.bootlin.com/linux/v7.0/source/scripts/Makefile.warn#L155.
> So maybe we need to sync some of those back to U-Boot as well?
> 
> Our scripts/Makefile.extrawarn is claimed[1] to be loosely based on Linux
> 6.1's, but it is actually quite different. So not sure how much we should be
> backporting and how.
> 
> [1] bd3f9ee679b4 ("kbuild: Bump the build system to 6.1")

We're likely a combination of mis-synced (assuming it's not inline with
6.1) and a case of needing to expand the new concept of
scripts/Makefile.XXX-u-boot for kbuild stuff to have a
Makefile.warn-u-boot for things we add.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260423/4d96f20d/attachment.sig>