RISC-V: hwprobe: Always use u64 for extension bits

Extensions are getting added quickly and their hwprobe bits will soon
exceed 31 (which pair values accommodate, since they're of type u64).
However, in one tree, where a bunch of extensions got merged prior to
zicboz, zicboz already got pushed to bit 32. Pushing it exposed a
32-bit compilation bug, since unsigned long was used instead of u64.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202310311801.hxduISrr-lkp@intel.com/
Fixes: 9c7646d5ff ("RISC-V: hwprobe: Expose Zicboz extension and its block size")
Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
Link: https://lore.kernel.org/r/20231101141908.192198-2-ajones@ventanamicro.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
This commit is contained in:
Andrew Jones
2023-11-01 15:19:09 +01:00
committed by Palmer Dabbelt
parent 82180b1fae
commit 777c0d761b

View File

@@ -169,7 +169,7 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
pair->value &= ~missing;
}
static bool hwprobe_ext0_has(const struct cpumask *cpus, unsigned long ext)
static bool hwprobe_ext0_has(const struct cpumask *cpus, u64 ext)
{
struct riscv_hwprobe pair;