Couple of clang warnings for Rockchip boards

[Tom Rini]

On Wed, Apr 29, 2026 at 08:18:14AM -0600, Simon Glass wrote:
> 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.

Yes, the LTO thing is a good example of something we shouldn't have done
really. Outside of sandbox you cannot just disable it.

-- 
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/20260429/9a34216e/attachment.sig>