[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba5b12e4-850c-445b-a1b1-0dc5f3905dda@csgroup.eu>
Date: Mon, 24 Feb 2025 13:01:45 +0100
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Anshuman Khandual <anshuman.khandual@....com>, linux-mm@...ck.org
Cc: steven.price@....com, Andrew Morton <akpm@...ux-foundation.org>,
Mark Rutland <mark.rutland@....com>, kvmarm@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
Jonathan Corbet <corbet@....net>, Marc Zyngier <maz@...nel.org>,
Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>,
Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt
<palmer@...belt.com>, Heiko Carstens <hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH V2 5/5] mm: Rename GENERIC_PTDUMP and PTDUMP_CORE
Le 17/02/2025 à 05:22, Anshuman Khandual a écrit :
> Platforms subscribe into generic ptdump implementation via GENERIC_PTDUMP.
> But generic ptdump gets enabled via PTDUMP_CORE. These configs combination
> is confusing as they sound very similar and does not differentiate between
> platform's feature subscription and feature enablement for ptdump. Rename
> the configs as ARCH_HAS_PTDUMP and PTDUMP making it more clear and improve
> readability.
>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Will Deacon <will@...nel.org>
> Cc: Jonathan Corbet <corbet@....net>
> Cc: Marc Zyngier <maz@...nel.org>
> Cc: Michael Ellerman <mpe@...erman.id.au>
> Cc: Nicholas Piggin <npiggin@...il.com>
> Cc: Paul Walmsley <paul.walmsley@...ive.com>
> Cc: Palmer Dabbelt <palmer@...belt.com>
> Cc: Heiko Carstens <hca@...ux.ibm.com>
> Cc: Vasily Gorbik <gor@...ux.ibm.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: linux-arm-kernel@...ts.infradead.org
> Cc: linux-doc@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> Cc: kvmarm@...ts.linux.dev
> Cc: linuxppc-dev@...ts.ozlabs.org
> Cc: linux-riscv@...ts.infradead.org
> Cc: linux-s390@...r.kernel.org
> Cc: linux-mm@...ck.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
> ---
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 7612c52e9b1e..5aef2aa4103c 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -43,6 +43,7 @@ config RISCV
> select ARCH_HAS_PMEM_API
> select ARCH_HAS_PREEMPT_LAZY
> select ARCH_HAS_PREPARE_SYNC_CORE_CMD
> + select ARCH_HAS_PTDUMP
Is it OK to drop the 'if MMU' from below ?
> select ARCH_HAS_PTE_DEVMAP if 64BIT && MMU
> select ARCH_HAS_PTE_SPECIAL
> select ARCH_HAS_SET_DIRECT_MAP if MMU
> @@ -112,7 +113,6 @@ config RISCV
> select GENERIC_IRQ_SHOW_LEVEL
> select GENERIC_LIB_DEVMEM_IS_ALLOWED
> select GENERIC_PCI_IOMAP
> - select GENERIC_PTDUMP if MMU
> select GENERIC_SCHED_CLOCK
> select GENERIC_SMP_IDLE_THREAD
> select GENERIC_TIME_VSYSCALL if MMU && 64BIT
Powered by blists - more mailing lists