[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <174197745246.735540.15365076503205188211.b4-ty@arm.com>
Date: Fri, 14 Mar 2025 18:37:39 +0000
From: Catalin Marinas <catalin.marinas@....com>
To: linux-arm-kernel@...ts.infradead.org,
Anshuman Khandual <anshuman.khandual@....com>
Cc: Will Deacon <will@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Andrey Ryabinin <ryabinin.a.a@...il.com>,
Alexander Potapenko <glider@...gle.com>,
Andrey Konovalov <andreyknvl@...il.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Ard Biesheuvel <ardb@...nel.org>,
Ryan Roberts <ryan.roberts@....com>,
linux-kernel@...r.kernel.org,
kasan-dev@...glegroups.com
Subject: Re: [PATCH V3] arm64/mm: Define PTDESC_ORDER
On Tue, 11 Mar 2025 10:27:10 +0530, Anshuman Khandual wrote:
> Address bytes shifted with a single 64 bit page table entry (any page table
> level) has been always hard coded as 3 (aka 2^3 = 8). Although intuitive it
> is not very readable or easy to reason about. Besides it is going to change
> with D128, where each 128 bit page table entry will shift address bytes by
> 4 (aka 2^4 = 16) instead.
>
> Let's just formalise this address bytes shift value into a new macro called
> PTDESC_ORDER establishing a logical abstraction, thus improving readability
> as well. While here re-organize EARLY_LEVEL macro along with its dependents
> for better clarity. This does not cause any functional change. Also replace
> all (PAGE_SHIFT - PTDESC_ORDER) instances with PTDESC_TABLE_SHIFT.
>
> [...]
Applied to arm64 (for-next/pgtable-cleanups), thanks!
[1/1] arm64/mm: Define PTDESC_ORDER
https://git.kernel.org/arm64/c/51ecb29f7a65
--
Catalin
Powered by blists - more mailing lists