Re: [PATCH v4 6/6] irqchip/gic-v3-its: Remove redundant check in its_vpe_db_proxy_unmap_locked()

[Marc Zyngier <maz@kernel.org>]

On Sat, 04 Jul 2026 17:32:44 +0100,
Radu Rendec <radu@rendec.net> wrote:
> 
> On Thu, 2026-07-02 at 11:30 +0800, Kemeng Shi wrote:
> > The high level functions already ensure that gic_rdists->has_rvpeid
> > is false before calling its_vpe_db_proxy_unmap_locked(), so we can
> > remove the redundant check in its_vpe_db_proxy_unmap_locked()
> 
> That's true for what the code is *today*. By removing the check, you're
> setting up a trap in case a new call to its_vpe_db_proxy_unmap_locked()
> is added in the future with the assumption that it will do "the right
> thing". The way I see these functions, they are not really "high level"
> and "low level". For example, its_vpe_db_proxy_map_locked() is called
> both by its_vpe_db_proxy_move() (which is another db_proxy function)
> and by its_vpe_send_cmd() directly.
> 
> FWIW, the code you're removing is just this:
>    0xffff8000806cf934 <+44>:	adrp	x0, 0xffff80008177e000 <static_ltree+784>
>    0xffff8000806cf938 <+48>:	add	x4, x0, #0x348
>    0xffff8000806cf93c <+52>:	ldr	x0, [x0, #840]
>    0xffff8000806cf940 <+56>:	ldrb	w0, [x0, #45]
>    0xffff8000806cf944 <+60>:	tbnz	w0, #0, 0xffff8000806cf9dc <its_vpe_db_proxy_unmap_locked+212>
> 
> I would argue that the gain in terms of both code size and speed is
> negligible (and these functions are subject to inlining anyway).

The main issue is that there are implicit dependencies between
multiple GIC features (RVPEID implies direct LPI), and the code is a
maze of indirections to handle a case or another depending on the
underlying HW quality of implementation.

I'd rather not remove this, and instead have a big fat WARN_ONCE(),
because we don't expect RVPEID without direct LPI (such HW should
simply be ignored).

	M.

-- 
Without deviation from the norm, progress is not possible.