From: Sourabh Jain <sourabhjain@linux.ibm.com>
To: kernel test robot <lkp@intel.com>, Ben Collins <bcollins@kernel.org>
Cc: oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org,
Madhavan Srinivasan <maddy@linux.ibm.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
shivang upadhyay <shivangu@linux.ibm.com>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Hari Bathini <hbathini@linux.ibm.com>
Subject: Re: arch/powerpc/kexec/core.c:217:20: sparse: sparse: incorrect type in assignment (different base types)
Date: Tue, 23 Dec 2025 18:27:19 +0530 [thread overview]
Message-ID: <fb309e19-9c2c-492c-abac-8aa6031f3124@linux.ibm.com> (raw)
In-Reply-To: <202512221405.VHPKPjnp-lkp@intel.com>
+Cc: PowerPC mailing list.
and added some comments below.
On 22/12/25 12:14, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 9448598b22c50c8a5bb77a9103e2d49f134c9578
> commit: 38c64dfe0af12778953846df5f259e913275cfe5 kexec: Include kernel-end even without crashkernel
> date: 6 weeks ago
> config: powerpc-randconfig-r111-20251222 (https://download.01.org/0day-ci/archive/20251222/202512221405.VHPKPjnp-lkp@intel.com/config)
> compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 42b3483ac4987cae1bdb632398e8a3ce2dea6633)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251222/202512221405.VHPKPjnp-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202512221405.VHPKPjnp-lkp@intel.com/
>
> sparse warnings: (new ones prefixed by >>)
>>> arch/powerpc/kexec/core.c:217:20: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int static [addressable] [toplevel] [usertype] kernel_end @@ got restricted __be32 [usertype] @@
> arch/powerpc/kexec/core.c:217:20: sparse: expected unsigned int static [addressable] [toplevel] [usertype] kernel_end
> arch/powerpc/kexec/core.c:217:20: sparse: got restricted __be32 [usertype]
If CONFIG_CRASH_DUMP is enabled (which is not done in config shared by
kernel test robot) sparse warn
about other assignments in the same file. And these warnings are not
limited to 32-bit.
../arch/powerpc/kexec/core.c:181:29: sparse: warning: incorrect type in
assignment (different base types)
../arch/powerpc/kexec/core.c:181:29: sparse: expected unsigned int
static [addressable] [toplevel] [usertype] crashk_base
../arch/powerpc/kexec/core.c:181:29: sparse: got restricted __be32
[usertype]
../arch/powerpc/kexec/core.c:183:29: sparse: warning: incorrect type in
assignment (different base types)
../arch/powerpc/kexec/core.c:183:29: sparse: expected unsigned int
static [addressable] [toplevel] [usertype] crashk_size
../arch/powerpc/kexec/core.c:183:29: sparse: got restricted __be32
[usertype]
../arch/powerpc/kexec/core.c:191:19: sparse: warning: incorrect type in
assignment (different base types)
../arch/powerpc/kexec/core.c:191:19: sparse: expected unsigned long
long static [addressable] [toplevel] mem_limit
../arch/powerpc/kexec/core.c:191:19: sparse: got restricted __be32
[usertype]
../arch/powerpc/kexec/core.c:217:20: sparse: warning: incorrect type in
assignment (different base types)
../arch/powerpc/kexec/core.c:217:20: sparse: expected unsigned int
static [addressable] [toplevel] [usertype] kernel_end
../arch/powerpc/kexec/core.c:217:20: sparse: got restricted __be32
[usertype]
CHECK ../arch/powerpc/kexec/core_32.c
To resolve these warnings:
Should we use __force tpyecast and silence the warnings?
for example:
kernel_end = (__force phys_addr_t) cpu_to_be_ulong(__pa(_end));
Or
Use proper data types __be<32|64> and duplicated the definition and
assignment? seems like bit too much.
Or
Do we have better way to handle these warnings? If yes, please share.
- Sourabh Jain
>
> vim +217 arch/powerpc/kexec/core.c
>
> 6f29c3298b1821 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-17 203
> 2e8e4f5b80e101 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-16 204 static int __init kexec_setup(void)
> 2e8e4f5b80e101 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-16 205 {
> 2e8e4f5b80e101 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-16 206 struct device_node *node;
> 2e8e4f5b80e101 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-16 207
> 2e8e4f5b80e101 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-16 208 node = of_find_node_by_path("/chosen");
> 2e8e4f5b80e101 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-16 209 if (!node)
> 2e8e4f5b80e101 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-16 210 return -ENOENT;
> 2e8e4f5b80e101 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-16 211
> 2e8e4f5b80e101 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-16 212 /* remove any stale properties so ours can be found */
> 38c64dfe0af127 arch/powerpc/kexec/core.c Ben Collins 2025-04-21 213 of_remove_property(node, of_find_property(node, kernel_end_prop.name,
> 38c64dfe0af127 arch/powerpc/kexec/core.c Ben Collins 2025-04-21 214 NULL));
> 2e8e4f5b80e101 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-16 215
> 2e8e4f5b80e101 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-16 216 /* information needed by userspace when using default_machine_kexec */
> ea961a828fe725 arch/powerpc/kernel/machine_kexec.c Anton Blanchard 2014-01-22 @217 kernel_end = cpu_to_be_ulong(__pa(_end));
> 79d1c712958f94 arch/powerpc/kernel/machine_kexec.c Nathan Fontenot 2012-10-02 218 of_add_property(node, &kernel_end_prop);
> 2e8e4f5b80e101 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth 2008-12-16 219
>
> :::::: The code at line 217 was first introduced by commit
> :::::: ea961a828fe7250e954f086d74d9323c3d44c3e4 powerpc: Fix endian issues in kexec and crash dump code
>
> :::::: TO: Anton Blanchard <anton@samba.org>
> :::::: CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
next prev parent reply other threads:[~2025-12-23 12:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-22 6:44 kernel test robot
2025-12-23 12:57 ` Sourabh Jain [this message]
2025-12-24 17:00 ` Sourabh Jain
-- strict thread matches above, loose matches on Subject: below --
2025-12-22 2:13 kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb309e19-9c2c-492c-abac-8aa6031f3124@linux.ibm.com \
--to=sourabhjain@linux.ibm.com \
--cc=bcollins@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=hbathini@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lkp@intel.com \
--cc=maddy@linux.ibm.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=ritesh.list@gmail.com \
--cc=shivangu@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®