Couple of clang warnings for Rockchip boards

[Quentin Schulz]

On 4/29/26 4:25 PM, Tom Rini wrote:
> 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.
> 

FYI, the Linux kernel defaults to CONFIG_WERROR=y. See commit 
3fe617ccafd6 ("Enable '-Werror' by default for all kernel builds") 
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3fe617ccafd6f5bb33c2391d6f4eeb41c1fd0151).

I wouldn't necessarily recommend to switch it on right now, but I think 
it could be a good idea in the mid-term. We're also very far behind in 
terms of warn flags compared to the kernel. Syncing will take some time 
though. For now I'm looking into enabling -Werror for host tools and 
this resulted in (so far) 21 patches.

Cheers,
Quentin