Re: [PATCH 1/1] irqchip/loongson-pch-pic: Fix vec_count reading for 32-bit and 64-bit

[Thomas Gleixner <tglx@kernel.org>]

On Fri, Apr 10 2026 at 09:30, George Guo wrote:
> From: George Guo <guodongtai@kylinos.cn>
>
> Commit 0370a5e740f2 ("irqchip/loongson-pch-pic: Adjust irqchip driver for
> 32BIT/64BIT") changed vec_count reading from readq() to readl() to support
> both 32-bit and 64-bit platforms. However, on virtual 64-bit platforms
> (QEMU 8.2.0) this causes incorrect vec_count value, leading to panic:

Is this problem limited to qemu?

> WARNING: drivers/acpi/irq.c:63 at acpi_register_gsi+0xe8/0x108
> Call Trace:
> [<900000000024c634>] show_stack+0x64/0x188
> [<9000000000245154>] dump_stack_lvl+0x6c/0x9c

Please trim your backtrace as documented:

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#backtraces

> @@ -343,7 +343,12 @@ static int pch_pic_init(phys_addr_t addr, unsigned long size, int vec_base,
>  		priv->table[i] = PIC_UNDEF_VECTOR;
>  
>  	priv->ht_vec_base = vec_base;
> -	priv->vec_count = ((readl(priv->base + 4) >> 16) & 0xff) + 1;
> +
> +	if (IS_ENABLED(CONFIG_64BIT))
> +		priv->vec_count = ((readq(priv->base) >> 48) & 0xff) + 1;
> +	else
> +		priv->vec_count = ((readl(priv->base + 4) >> 16) & 0xff) + 1;

This does not make sense at all.

     readl(base + 4) >> 16

is fully equivalent to

     readq(base) >> 48

on a little endian machine, no?

This needs a better explanation in the change log about the root cause
and why this is the correct solution to fix the problem.

If there is no other solution then this needs a big fat comment in the
code explaining the reason. Otherwise the next AI agent will notice the
equivalence and people will send cleanup patches....

Thanks,

        tglx