From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 71D1734FF64 for ; Tue, 27 Jan 2026 13:26:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769520386; cv=none; b=Gzrgeww4eQVvDFTX4RzDLN6d45PmInCrXNzCIv/DJq5TwQW4LXv6y2VBHOskOw8V/KuVvNz3VblVYs+V2yfuI0ppbKRGWDRrhxhYifkxhcNR88Qujj297BV5yUU4YzPKpOr2gPQmEXlhzmDEYXcvldNW04pYdpilNQ03wGhk9XI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769520386; c=relaxed/simple; bh=/PnxrcR8aB2yaLAow1OWvdCzHIxrM6Kx2T92W6ORpK0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=S/58d6bWa2zA/c1/apg9cWUt0USBLcOUpmgtWknuyXs7y3LLR8ZMBv3FyUoOw2jH5jntX4YYjAClk3Gjr5D1L9WJoleZAvuEmBw2pUuPY3n34drGiGNeHDXK+ith3fsl69DAQbAu27zMzkKsNu4yQesgXOl/4TYPFRUXd5jziGw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2CC611595; Tue, 27 Jan 2026 05:26:17 -0800 (PST) Received: from [10.1.37.210] (XHFQ2J9959.cambridge.arm.com [10.1.37.210]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9F9E53F632; Tue, 27 Jan 2026 05:26:21 -0800 (PST) Message-ID: <63283f63-f62f-4e8b-9611-94e6a64c49b7@arm.com> Date: Tue, 27 Jan 2026 13:26:20 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 04/13] arm64: mm: Push __TLBI_VADDR() into __tlbi_level() To: Jonathan Cameron Cc: Will Deacon , Ard Biesheuvel , Catalin Marinas , Mark Rutland , Linus Torvalds , Oliver Upton , Marc Zyngier , Dev Jain , Linu Cherian , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260119172202.1681510-1-ryan.roberts@arm.com> <20260119172202.1681510-5-ryan.roberts@arm.com> <20260127113758.00005bea@huawei.com> From: Ryan Roberts Content-Language: en-GB In-Reply-To: <20260127113758.00005bea@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27/01/2026 11:37, Jonathan Cameron wrote: > On Mon, 19 Jan 2026 17:21:51 +0000 > Ryan Roberts wrote: > >> From: Will Deacon >> >> The __TLBI_VADDR() macro takes an ASID and an address and converts them >> into a single argument formatted correctly for a TLB invalidation >> instruction. >> >> Rather than have callers worry about this (especially in the case where >> the ASID is zero), push the macro down into __tlbi_level() via a new >> __tlbi_level_asid() helper. >> >> Signed-off-by: Will Deacon >> Reviewed-by: Linu Cherian >> Signed-off-by: Ryan Roberts > One comment inline, but not particularly important given it's > about reducing readability of a workaround a little > > Reviewed-by: Jonathan Cameron > >> @@ -674,6 +679,7 @@ static inline bool huge_pmd_needs_flush(pmd_t oldpmd, pmd_t newpmd) >> #define huge_pmd_needs_flush huge_pmd_needs_flush >> >> #undef __tlbi_user >> +#undef __TLBI_VADDR >> #endif >> >> #endif >> diff --git a/arch/arm64/kernel/sys_compat.c b/arch/arm64/kernel/sys_compat.c >> index 4a609e9b65de..ad4857df4830 100644 >> --- a/arch/arm64/kernel/sys_compat.c >> +++ b/arch/arm64/kernel/sys_compat.c >> @@ -36,7 +36,7 @@ __do_compat_cache_op(unsigned long start, unsigned long end) >> * The workaround requires an inner-shareable tlbi. >> * We pick the reserved-ASID to minimise the impact. >> */ >> - __tlbi(aside1is, __TLBI_VADDR(0, 0)); >> + __tlbi(aside1is, 0UL); > > Dropping the explicit ASID sort of looses some meaning here vs the comment just > above it. Meh, it's in a work around so most folk will ignore it anyway > if reading this code, so I don't mind that much. Agreed; personally I think the comment makes it clear what that zero is. Thanks for all your reviews so far! > >> dsb(ish); >> } >> >