From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.mindbit.ro (xs1.mindbit.ro [80.86.107.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5DB4133B97D for ; Sat, 4 Jul 2026 16:32:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.86.107.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783182771; cv=none; b=FMEbTTdZXyJU6PtNRwaFdnZNwVXIifT3sSLG9IO4ZLw17WHQYJLTwU6SPU1CUuKjmLX2feHbiCNA/F6dxkRjoWLMD9Jmp6cFoyqLU7WVep6IytZXfcFOwnTCA0+Io84cGiJKnN8WZYxOHBoThvg/GMUpUAmu5OTFw5pVI5zeW+s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783182771; c=relaxed/simple; bh=F4TeNEcofBTdksZhqfZninylEuF/u81GkFmindU3kao=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=gDb6r2iPMLZipLiu5ZdbKV2S3S7rV921AKKX1mWmv0+xRIqDKfpdjlMJ1yMb9PCGBV64W8es7dVNo5bsDJ/assBFgQ0GihjhNdgayzEuam6Qq+p8ijir2D2E7gp3/nd7YiVCeKUxX+be9l5DuHhfaqI4TeOA4aXxjnHOFNbqOXY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=rendec.net; spf=pass smtp.mailfrom=rendec.net; dkim=pass (2048-bit key) header.d=rendec.net header.i=@rendec.net header.b=R1A9bHV2; arc=none smtp.client-ip=80.86.107.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=rendec.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rendec.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rendec.net header.i=@rendec.net header.b="R1A9bHV2" Received: from dog.kanata.rendec.net (pool-174-112-193-187.cpe.net.cable.rogers.com [174.112.193.187]) by mail.mindbit.ro (Postfix) with ESMTPSA id 6D520C24ED; Sat, 4 Jul 2026 19:32:46 +0300 (EEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.mindbit.ro 6D520C24ED DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rendec.net; s=default; t=1783182767; bh=tLPrBME3JJr4LVfH3gzcShU2Chrxq/q7aoyH5uoRdUw=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=R1A9bHV2ydnVTr2QQhjVCbI3JKDUkzKrAl++4m5fvIyHOZLzldkwFoAC4Drf7YvE2 i7lz6VZVzzbtWIVCykaTdEsToA9WzU/eTnpcNTYjeS4KZ+GkPRI0HIxtD1wQ7Pv3Gc QYzYEpeOtmCBBbSCaTQz6+2abnm2r7XsOBc1j2V8onwNrxXo1k79Vv23/I1MRnmOyh DG0upo5kIuyBKbYfmRaD55Nv64wkoV3zDPPdZJYphM4aaJ+TgnvgAKstrlttcYzpiL AYIiuHEpwgou4JiIreyi2SG2Tzk2IzmmjiSFgYZtU0LFfq69NRtydgsgl2uMdAtlWM QF1q9lvnBKDGg== Message-ID: <1d141ab4b472533ba728c65201ea7cb74047acba.camel@rendec.net> Subject: Re: [PATCH v4 6/6] irqchip/gic-v3-its: Remove redundant check in its_vpe_db_proxy_unmap_locked() From: Radu Rendec To: Kemeng Shi , maz@kernel.org, tglx@kernel.org, jason@lakedaemon.net, lpieralisi@kernel.org Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Date: Sat, 04 Jul 2026 12:32:44 -0400 In-Reply-To: <20260702033050.1583-7-shikemeng@huaweicloud.com> References: <20260702033050.1583-1-shikemeng@huaweicloud.com> <20260702033050.1583-7-shikemeng@huaweicloud.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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 0xffff8000806cf938 <+48>: add x4, x0, #0x348 0xffff8000806cf93c <+52>: ldr x0, [x0, #840] 0xffff8000806cf940 <+56>: ldrb w0, [x0, #45] 0xffff8000806cf944 <+60>: tbnz w0, #0, 0xffff8000806cf9dc I would argue that the gain in terms of both code size and speed is negligible (and these functions are subject to inlining anyway). > Signed-off-by: Kemeng Shi > --- > =C2=A0drivers/irqchip/irq-gic-v3-its.c | 4 ---- > =C2=A01 file changed, 4 deletions(-) >=20 > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v= 3-its.c > index 120f6f29e978..b0069fbe1e69 100644 > --- a/drivers/irqchip/irq-gic-v3-its.c > +++ b/drivers/irqchip/irq-gic-v3-its.c > @@ -3801,10 +3801,6 @@ static const struct irq_domain_ops its_domain_ops = =3D { > =C2=A0 */ > =C2=A0static void its_vpe_db_proxy_unmap_locked(struct its_vpe *vpe) > =C2=A0{ > - /* GICv4.1 doesn't use a proxy, so nothing to do here */ > - if (gic_rdists->has_rvpeid) > - return; > - > =C2=A0 /* Already unmapped? */ > =C2=A0 if (vpe->vpe_proxy_event =3D=3D -1) > =C2=A0 return;