On Sat, 04 Jul 2026 17:32:44 +0100,
Radu Rendec [off-list ref] wrote:

On Thu, 2026-07-02 at 11:30 +0800, Kemeng Shi wrote:

quoted

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.