Couple of clang warnings for Rockchip boards

[Simon Glass]

Hi Tom,

On Mon, 27 Apr 2026 at 08:46, Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Apr 27, 2026 at 11:54:09PM +1200, Simon Glass wrote:
> > Hi Quentin,
> >
> > On Thu, 23 Apr 2026 at 22:24, Quentin Schulz <quentin.schulz at cherry.de> 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.
> > >
> > > 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
> >
> > This is strange though, because people should see the warnings during
> > development. I wonder if it is scrolling off the screen.
> >
> > One my bugbears is non-actionable output. When the build succeeds
> > (with no warnings) I see no output, using 'buildman -I --board xxx -w
> > -o /tmp/b/xxx' or in fact these days 'um build xxx'. This uses 'make
> > -s' under the hood, so that it doesn't print a huge list of filenames,
> > etc. I also sometimes do a 'fresh' build with 'um build -F xxx' to
> > check everything is clean ('buildman -m' does something similar).
> >
> > Note that buildman returns exit code 101 if there are any warnings, so
> > the build basically fails.
> >
> > >
> > > No defconfig seems to be setting this option, not sure exactly why that is.
> >
> > To me this is a difference between 'functionality' options and
> > development options. Putting development options in Kconfig makes it
> > harder to turn them on and off, since you must either edit the
> > defconfig or edit the .config file. It is easier to just pass an
> > environment variable.
>
> The point of a configuration is that it configures the build. Stuff in
> environment (directly or make FOO=bar) is a workaround and anti-pattern.
> Having to run one of the config front-end to change the config is a
> feature, and good thing.

To give an example, we have boards which enable LTO, but it is
sometimes useful to disable it during development - it used to be a
huge time sync but something seems to have changed recently, as I
don't see much of a performance gap now. We don't want people
disabling LTO in the defconfig, though. The same applies for things
like V=1

So I think there are build features which are of no use to end-users,
but are helpful for development. That is the distinction we have had
for a while and it would be a shame to lose it.

Regards,
Simon