[{"id":3680738,"web_url":"http://patchwork.ozlabs.org/comment/3680738/","msgid":"<20260422175116.GF41863@bill-the-cat>","list_archive_url":null,"date":"2026-04-22T17:51:16","subject":"Re: Couple of clang warnings for Rockchip boards","submitter":{"id":65875,"url":"http://patchwork.ozlabs.org/api/people/65875/","name":"Tom Rini","email":"trini@konsulko.com"},"content":"On Wed, Apr 22, 2026 at 03:25:55PM +0200, Quentin Schulz wrote:\n\n> Hi all,\n> \n> I'm looking into force-enabling CONFIG_WERROR for all Rockchip SoCs. First,\n> let me know if this is a bad idea :)\n\nThis is how CI works, so this part should go fine.\n\n> gcc version 15.2.1 20250808 (Red Hat Cross 15.2.1-1) (GCC) for both ARM and\n> Aarch64 machines report no warnings (built with a config fragment enabling\n> CONFIG_WERROR).\n> \n> For clang, I went for cross-compiling using either\n> make HOSTCC=clang CROSS_COMPILE=arm-linux-gnu- CC=clang O=build/ ...\n> or\n> make HOSTCC=clang CROSS_COMPILE=aarch64-linux-gnu- CC=clang O=build/ ...\n\nI'm adding in Dmitrii here because I thought we had fixed clang builds\nagain rather recently, but I haven't put them in CI and I thought we\nmight also need another Kbuild re-sync for a few more things too.\n\n> First things first, I can't even build any of the Aarch32/ARM with clang for\n> some reason, so this only applies for Aarch64 Rockchip platforms.\n> \n> Some platforms couldn't be built due to hitting the max TPL limit (e.g.\n> PX30).\n\nI've also run in to this over the years trying to test clang and having\nLTO not work, or be very much larger than expected. Just FYI.\n\n> clang version 21.1.8 (Fedora 21.1.8-4.fc43) (or clang version 22.1.1 (Fedora\n> 22.1.1-2.fc44), doesn't matter) issues three warnings:\n> \n> 1. Chromebooks EC fails to build:\n> In file included from\n> /home/qschulz/work/upstream/u-boot/drivers/misc/cros_ec.c:21:\n> In file included from\n> /home/qschulz/work/upstream/u-boot/include/cros_ec.h:12:\n> /home/qschulz/work/upstream/u-boot/include/ec_commands.h:3578:2: error:\n> field within 'struct ec_params_charge_state' is less aligned than 'union\n> ec_params_charge_state::(anonymous at\n> /home/qschulz/work/upstream/u-boot/include/ec_commands.h:3578:2)' and is\n> usually due to 'struct ec_params_charge_state' being packed, which can lead\n> to unaligned accesses [-Werror,-Wunaligned-access]\n> 3578 | union {\n> | ^\n> \n> The following\n> \n> diff --git a/include/ec_commands.h b/include/ec_commands.h\n> index 23597d28b2c..c5f9777c0c7 100644\n> --- a/include/ec_commands.h\n> +++ b/include/ec_commands.h\n> @@ -3575,7 +3575,7 @@ enum charge_state_params {\n> \n> struct __ec_todo_packed ec_params_charge_state {\n> \tuint8_t cmd;\t\t\t\t/* enum charge_state_command */\n> -\tunion {\n> +\tunion __ec_todo_packed {\n> \t\tstruct __ec_align1 {\n> \t\t\t/* no args */\n> \t\t} get_state;\n> \n> seems to fix it. The upstream EC git repo\n> (https://chromium.googlesource.com/chromiumos/platform/ec) has a commit with\n> more changes, see 65da9cc08766 (\"include/ec_commands.h: Fix unaligned access\n> warnings\"). It doesn't apply cleanly (and I haven't looked into other\n> patches to backport for this to apply cleanly). I'm not sure what we're\n> supposed to do here? I also don't have a Chromebook to test.\n\nI would just go with making the changes we need to make here, and cc'ing\nsome board maintainers for functional testing.\n\n> 2. RK3528, RK3576 and RK3588 boards fail with (replace rk3528 in path for\n> the other SoCs)\n> \n> /home/qschulz/work/upstream/u-boot/arch/arm/mach-rockchip/rk3528/rk3528.c:98:45:\n> error: value size does not match register size specified by the constraint\n> and modifier [-Werror,-Wasm-operand-widths]\n> 98 | asm volatile(\"msr cntfrq_el0, %0\" : : \"r\"\n> (CONFIG_COUNTER_FREQUENCY));\n> | ^\n> include/generated/autoconf.h:372:34: note: expanded from macro\n> 'CONFIG_COUNTER_FREQUENCY'\n> 372 | #define CONFIG_COUNTER_FREQUENCY 24000000\n> | ^\n> /home/qschulz/work/upstream/u-boot/arch/arm/mach-rockchip/rk3528/rk3528.c:98:32:\n> note: use constraint modifier \"w\"\n> 98 | asm volatile(\"msr cntfrq_el0, %0\" : : \"r\"\n> (CONFIG_COUNTER_FREQUENCY));\n> | ^~\n> | %w0\n> \n> Note that all Rockchip SoCs have CONFIG_COUNTER_FREQUENCY set to 24000000.\n> \n> The cntfrq_el0 register is 64b (https://developer.arm.com/documentation/ddi0601/2026-03/AArch64-Registers/CNTFRQ-EL0--Counter-timer-Frequency-Register?lang=en),\n> though the top 32b are reserved. Android decided to ignore this warning in\n> the Little Kernel with https://android.googlesource.com/kernel/lk/+/923541d4c23565a47d020d84202a6f77d22fc149%5E%21/.\n> \n> I tried to follow clang's recommendation and switch this to %w0 but it fails\n> with:\n> \n> /tmp/rk3588-a0a4b8.s: Assembler messages:\n> /tmp/rk3588-a0a4b8.s:87: Error: operand mismatch -- `msr cntfrq_el0,w9'\n> /tmp/rk3588-a0a4b8.s:87: Info: did you mean this?\n> /tmp/rk3588-a0a4b8.s:87: Info: \tmsr cntfrq_el0, x9\n> clang: error: assembler command failed with exit code 1 (use -v to see\n> invocation)\n> \n> I tried casting CONFIG_COUNTER_FREQUENCY into a u64 and it builds and no\n> magic smoke when booting a board. Whether this is the proper fix, I don't\n> know, but the warning is then gone. We could also decide to ignore the\n> warning like for Android's Little Kernel (where and how much this is used is\n> unclear as the repo isn't seeing much activity).\n> \n> The register documentation indicates this is not used by the hardware at\n> all, so even if it was broken, we probably wouldn't see a difference?\n\nCan we define it as 24000000ULL? Maybe. If not 0x16e3600ULL with a\ncomment should work.\n\n> 3. Boards building USB TCPM fail with\n> \n> In file included from\n> /home/qschulz/work/upstream/u-boot/drivers/usb/tcpm/tcpm-uclass.c:12:\n> In file included from\n> /home/qschulz/work/upstream/u-boot/include/usb/tcpm.h:12:\n> /home/qschulz/work/upstream/u-boot/include/usb/pd.h:212:2: error: field\n> within 'struct pd_message' is less aligned than 'union\n> pd_message::(anonymous at\n> /home/qschulz/work/upstream/u-boot/include/usb/pd.h:212:2)' and is usually\n> due to 'struct pd_message' being packed, which can lead to unaligned\n> accesses [-Werror,-Wunaligned-access]\n> 212 | union {\n> | ^\n> \n> This file is apparently adapted from upstream Linux, where the code is\n> identical for that struct. So not sure what to do here.\n\nI'm not sure either.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=konsulko.com header.i=@konsulko.com header.a=rsa-sha256\n header.s=google header.b=c/PRZUX6;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=85.214.62.61; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=konsulko.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=konsulko.com header.i=@konsulko.com\n header.b=\"c/PRZUX6\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=konsulko.com","phobos.denx.de;\n spf=pass smtp.mailfrom=trini@konsulko.com"],"Received":["from phobos.denx.de (phobos.denx.de [85.214.62.61])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g16Gm6M5Jz1y2d\n\tfor ; Thu, 23 Apr 2026 03:51:28 +1000 (AEST)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 4C3B4842C4;\n\tWed, 22 Apr 2026 19:51:25 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id 88FC9842D7; Wed, 22 Apr 2026 19:51:23 +0200 (CEST)","from mail-oa1-x42.google.com (mail-oa1-x42.google.com\n [IPv6:2001:4860:4864:20::42])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id EAAD884255\n for ; Wed, 22 Apr 2026 19:51:20 +0200 (CEST)","by mail-oa1-x42.google.com with SMTP id\n 586e51a60fabf-40f1ffba6a0so4060804fac.0\n for ; Wed, 22 Apr 2026 10:51:20 -0700 (PDT)","from bill-the-cat (fixed-189-203-106-235.totalplay.net.\n [189.203.106.235]) by smtp.gmail.com with ESMTPSA id\n 006d021491bc7-694984114f5sm3504387eaf.7.2026.04.22.10.51.18\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Wed, 22 Apr 2026 10:51:18 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,\n DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED,\n SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=konsulko.com; s=google; t=1776880279; x=1777485079; darn=lists.denx.de;\n h=in-reply-to:content-disposition:mime-version:references:message-id\n :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;\n bh=TKjtqQWsZUwJWnj9Yuqm1QvfU9yEhcgCi0KdCsEvitw=;\n b=c/PRZUX6VylqVoTyIKnKMQwdmihXZb+rVykUYm5ZHsrj50ffr+Xsxtp1yhvLFBi7UE\n CjMYumo3/3ec24yMKs9A4ObDG+E58SzryazV+b5lNaEIPT1PLVTzlhNjCwFj0IJcemJ5\n yNVnHXCnqtTUbCjH/ktqy/pJo7Qdz4CTab/wQ=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776880279; x=1777485079;\n h=in-reply-to:content-disposition:mime-version:references:message-id\n :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc\n :subject:date:message-id:reply-to;\n bh=TKjtqQWsZUwJWnj9Yuqm1QvfU9yEhcgCi0KdCsEvitw=;\n b=LEAICvOCCglmXfAxxW69Inl1inGJ2l8VYbnv36APTjQqq2bkS6QFeOSlHDf/RWzgyE\n HNwVYWaT6DfJmYzoKiGmC/PBNsT5tl2kqdUT4ezDILiyO7QkmW9LVv8CLYgXXzHOzMOv\n d6vSLsvxshZCuNCXNY8zQsu225qLLRwCdn2U6jnlvUm8P4KskBt6Pr/pKQ/9ZNj/TM9H\n TAUMzoE+79lnFqxQEpBPzE6qahyyUDPjCTscvAvJM1gMLYooCl2P2oEN2TXV7LZtuUT6\n uIIzulVdP0wrmkmLTmLD9THu0vW8jZzcnewAyTTflR/E3zuChpM7S+7T2NQ7BLiWxR0+\n 3FvQ==","X-Gm-Message-State":"AOJu0YwJxzz+xBm4ofNce+9oMU4CT5RSFkwSg6Q6wlLzu5+KHLq7hxp/\n iyXZNPG0si+ZpeUko86+TEHnFrMeQkjrxwuwzvwRSoX+p9U5OqKMyaTDAeathWDFHxY=","X-Gm-Gg":"AeBDiev26hLm3AOQOYtvL9kg4XnLPgAkiRpfHLHO0xVz4pdQ83PWnigCAeE/x8aRBAN\n gjD3fAP0Papk/vlY77qeNdtopJ8TGP61lKZci2BK+dps5P7i/Bg0sueN76N1zQW2CufX4vgyD+I\n 0Q2rCAWqQHuZBSJcuAsCxnvNS6Cr+YZjoIOdTPUEJg5mPjUr0mzf0toXGF+2GALMxdToMsPgqXG\n pTvxE+vv1w7Rnqmq4s66wuQiOHqZ8mjDeq9xuT+ypvTs+aUK9IfBFRndUCB/KCI+1YB1mELav+U\n h7ZkZrn1GoXkJd97ETxhA5K51EJYRmhq1YMwdsF/6aSq0oTekIxWLFrh+2A6O1aTNCu3AfDaeO2\n WsuxqbrdYVNT5XsejvUuK3/U9yl65EV0P3Ksh0BMRv6UxsdSwRtWfvNZ2sZ0OG3K3sCRInDRNv9\n VZxOHkoqX2z2zr7a4ZUJvjGTDDbmfDdZ4nqCfq/s7whISh8MWjbBMWeItUQlPGTxrWzZrAfjosC\n OHYo3vQcQLnvuxNpwPHNzajj0utTqctANoOsAP4w0du3+o5SSR1J5lf8wmCfg==","X-Received":"by 2002:a05:6820:1891:b0:694:9fa0:aa4a with SMTP id\n 006d021491bc7-6949fa0bc40mr3569033eaf.44.1776880279490;\n Wed, 22 Apr 2026 10:51:19 -0700 (PDT)","Date":"Wed, 22 Apr 2026 11:51:16 -0600","From":"Tom Rini ","To":"Quentin Schulz ","Cc":"U-Boot Mailing List ,\n Simon Glass ,\n Philipp Tomsich ,\n Kever Yang , Jonas Karlman ,\n Xuhui Lin , Heiko Stuebner ,\n Marek Vasut ,\n Sebastian Reichel ,\n Dmitrii Sharshakov ,\n Ilias Apalodimas ","Subject":"Re: Couple of clang warnings for Rockchip boards","Message-ID":"<20260422175116.GF41863@bill-the-cat>","References":"","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha512;\n protocol=\"application/pgp-signature\"; boundary=\"WiPuCqNHHhyqrAce\"","Content-Disposition":"inline","In-Reply-To":"","X-Clacks-Overhead":"GNU Terry Pratchett","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}}]