arch/arm64/Kconfig | 2 +- lib/Kconfig | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-)
From: Conor Dooley <conor.dooley@microchip.com>
Randy pointed out that the newly added GENERIC_CPU_CACHE_MAINTENANCE
was unusual, in that it selected an ARCH_HAS_... option, unlikely
anything else in lib/Kconfig. Switch things around, so that arm64
selects ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION and then
GENERIC_CPU_CACHE_MAINENANCE will in turn be automatically enabled.
Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
Catalin, you voiced a take on this already apparently that lead to the
current implementation so I'd like an ack from you or Will here.
My comment on the original thread, in response to Randy saying it was
backwards, that accompanied the diff was:
Maybe it is backwards, but I feel like this way is more logical. ARM64
has memregion invalidation only because this generic approach is
enabled, so the arch selects what it needs to get the support.
Alternatively, something like (diff was here) implies (to me at least)
that arm64 has memregion invalidation as an architectural feature and
that the GENERIC_CPU_CACHE_MAINTENANCE option is a just common
cross-arch code, like generic entry etc, rather than being the option
gating the drivers that provide the feature in the first place.
Ultimately, the .config produced is the same either way, just depends on
what impression you want to give in the arch Kconfig, which might not
really be a big deal, just semantics. Either way, I'd like an ack :)
Cheers,
Conor.
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will@kernel.org>
CC: linux-arm-kernel@lists.infradead.org
CC: linux-kernel@vger.kernel.org
---
arch/arm64/Kconfig | 2 +-
lib/Kconfig | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5f7f63d24931..75b2507f7eb2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -21,6 +21,7 @@ config ARM64
select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
select ARCH_HAS_CACHE_LINE_SIZE
select ARCH_HAS_CC_PLATFORM
+ select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
select ARCH_HAS_CURRENT_STACK_POINTER
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEBUG_VM_PGTABLE
@@ -146,7 +147,6 @@ config ARM64
select GENERIC_ARCH_TOPOLOGY
select GENERIC_CLOCKEVENTS_BROADCAST
select GENERIC_CPU_AUTOPROBE
- select GENERIC_CPU_CACHE_MAINTENANCE
select GENERIC_CPU_DEVICES
select GENERIC_CPU_VULNERABILITIES
select GENERIC_EARLY_IOREMAP
diff --git a/lib/Kconfig b/lib/Kconfig
index 09aec4a1e13f..ac223e627bc5 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -544,8 +544,9 @@ config ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
bool
config GENERIC_CPU_CACHE_MAINTENANCE
- bool
- select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
+ def_bool y
+ depends on ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
+ depends on ARM64
config ARCH_HAS_MEMREMAP_COMPAT_ALIGN
bool
--
2.51.0On Wed, Nov 19, 2025 at 07:08:27PM +0000, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > Randy pointed out that the newly added GENERIC_CPU_CACHE_MAINTENANCE > was unusual, in that it selected an ARCH_HAS_... option, unlikely > anything else in lib/Kconfig. Switch things around, so that arm64 > selects ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION and then > GENERIC_CPU_CACHE_MAINENANCE will in turn be automatically enabled. > > Suggested-by: Randy Dunlap <rdunlap@infradead.org> > Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > --- > Catalin, you voiced a take on this already apparently that lead to the > current implementation so I'd like an ack from you or Will here. > My comment on the original thread, in response to Randy saying it was > backwards, that accompanied the diff was: > Maybe it is backwards, but I feel like this way is more logical. ARM64 > has memregion invalidation only because this generic approach is > enabled, so the arch selects what it needs to get the support. > Alternatively, something like (diff was here) implies (to me at least) > that arm64 has memregion invalidation as an architectural feature and > that the GENERIC_CPU_CACHE_MAINTENANCE option is a just common > cross-arch code, like generic entry etc, rather than being the option > gating the drivers that provide the feature in the first place. > Ultimately, the .config produced is the same either way, just depends on > what impression you want to give in the arch Kconfig, which might not > really be a big deal, just semantics. Either way, I'd like an ack :) I really don't remember what I said before ;). As you describe above, there are two somewhat complementary options - ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION where an arch port can provide this API and GENERIC_CPU_CACHE_MAINTENANCE as a generic way of providing the same API. arm64 does the latter. > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 5f7f63d24931..75b2507f7eb2 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -21,6 +21,7 @@ config ARM64 > select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE > select ARCH_HAS_CACHE_LINE_SIZE > select ARCH_HAS_CC_PLATFORM > + select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > select ARCH_HAS_CURRENT_STACK_POINTER > select ARCH_HAS_DEBUG_VIRTUAL > select ARCH_HAS_DEBUG_VM_PGTABLE > @@ -146,7 +147,6 @@ config ARM64 > select GENERIC_ARCH_TOPOLOGY > select GENERIC_CLOCKEVENTS_BROADCAST > select GENERIC_CPU_AUTOPROBE > - select GENERIC_CPU_CACHE_MAINTENANCE > select GENERIC_CPU_DEVICES > select GENERIC_CPU_VULNERABILITIES > select GENERIC_EARLY_IOREMAP > diff --git a/lib/Kconfig b/lib/Kconfig > index 09aec4a1e13f..ac223e627bc5 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -544,8 +544,9 @@ config ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > bool > > config GENERIC_CPU_CACHE_MAINTENANCE > - bool > - select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > + def_bool y > + depends on ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > + depends on ARM64 That's what we do if GENERIC_CPU_CACHE_MAINTENANCE depends on some arch code but that's not the case here. GENERIC_CPU_CACHE_MAINTENANCE is an alternative implementation that an arch can select if it does not provide its own. I find the current code without the above patch better. Maybe what gets confusing here is that the core code uses ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION directly. A more involved fix would be something like: config CPU_CACHE_INVALIDATE_MEMREGION def_bool y depends on ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION || GENERIC_CPU_CACHE_MAINTENANCE and then go and change all the uses of ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION. Up to you, the current code also works for me. -- Catalin
On Thu, Nov 20, 2025 at 05:30:46PM +0000, Catalin Marinas wrote: > On Wed, Nov 19, 2025 at 07:08:27PM +0000, Conor Dooley wrote: > > index 09aec4a1e13f..ac223e627bc5 100644 > > --- a/lib/Kconfig > > +++ b/lib/Kconfig > > @@ -544,8 +544,9 @@ config ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > > bool > > > > config GENERIC_CPU_CACHE_MAINTENANCE > > - bool > > - select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > > + def_bool y > > + depends on ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > > + depends on ARM64 > > That's what we do if GENERIC_CPU_CACHE_MAINTENANCE depends on some arch > code but that's not the case here. GENERIC_CPU_CACHE_MAINTENANCE is an > alternative implementation that an arch can select if it does not > provide its own. I find the current code without the above patch better. Right, I am going to leave it as-is for now then. That's both you and I (and presumably Jonathan) finding the current form more natural. Sorry Randy! > > Maybe what gets confusing here is that the core code uses > ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION directly. A more involved fix > would be something like: > > config CPU_CACHE_INVALIDATE_MEMREGION > def_bool y > depends on ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION || > GENERIC_CPU_CACHE_MAINTENANCE > > and then go and change all the uses of > ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION. > > Up to you, the current code also works for me. > > -- > Catalin
On 11/20/25 11:29 AM, Conor Dooley wrote: > On Thu, Nov 20, 2025 at 05:30:46PM +0000, Catalin Marinas wrote: >> On Wed, Nov 19, 2025 at 07:08:27PM +0000, Conor Dooley wrote: >>> index 09aec4a1e13f..ac223e627bc5 100644 >>> --- a/lib/Kconfig >>> +++ b/lib/Kconfig >>> @@ -544,8 +544,9 @@ config ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION >>> bool >>> >>> config GENERIC_CPU_CACHE_MAINTENANCE >>> - bool >>> - select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION >>> + def_bool y >>> + depends on ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION >>> + depends on ARM64 >> >> That's what we do if GENERIC_CPU_CACHE_MAINTENANCE depends on some arch >> code but that's not the case here. GENERIC_CPU_CACHE_MAINTENANCE is an >> alternative implementation that an arch can select if it does not >> provide its own. I find the current code without the above patch better. > > Right, I am going to leave it as-is for now then. That's both you and I > (and presumably Jonathan) finding the current form more natural. Sorry > Randy! Thanks. I tried. I still say that it makes no sense for something generic (GENERIC_CPU_CACHE_MAINTENANCE in lib/Kconfig) to inform the config system that the config has something $ARCH-specific (ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION). >> >> Maybe what gets confusing here is that the core code uses >> ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION directly. A more involved fix >> would be something like: >> >> config CPU_CACHE_INVALIDATE_MEMREGION >> def_bool y >> depends on ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION || >> GENERIC_CPU_CACHE_MAINTENANCE >> >> and then go and change all the uses of >> ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION. >> >> Up to you, the current code also works for me. >> >> -- >> Catalin -- ~Randy
On Thu, Nov 20, 2025 at 12:13:10PM -0800, Randy Dunlap wrote: > On 11/20/25 11:29 AM, Conor Dooley wrote: > > On Thu, Nov 20, 2025 at 05:30:46PM +0000, Catalin Marinas wrote: > >> On Wed, Nov 19, 2025 at 07:08:27PM +0000, Conor Dooley wrote: > >>> index 09aec4a1e13f..ac223e627bc5 100644 > >>> --- a/lib/Kconfig > >>> +++ b/lib/Kconfig > >>> @@ -544,8 +544,9 @@ config ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > >>> bool > >>> > >>> config GENERIC_CPU_CACHE_MAINTENANCE > >>> - bool > >>> - select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > >>> + def_bool y > >>> + depends on ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > >>> + depends on ARM64 > >> > >> That's what we do if GENERIC_CPU_CACHE_MAINTENANCE depends on some arch > >> code but that's not the case here. GENERIC_CPU_CACHE_MAINTENANCE is an > >> alternative implementation that an arch can select if it does not > >> provide its own. I find the current code without the above patch better. > > > > Right, I am going to leave it as-is for now then. That's both you and I > > (and presumably Jonathan) finding the current form more natural. Sorry > > Randy! > > Thanks. I tried. > > I still say that it makes no sense for something generic > (GENERIC_CPU_CACHE_MAINTENANCE in lib/Kconfig) to inform the > config system that the config has something $ARCH-specific > (ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION). Yes, that's not great either but the solution with the GENERIC depending on ARCH does work since there's no actual dependency between them. As an alternative, I'm happy for arm64 to select both the ARCH and GENERIC options if you think that works better. -- Catalin
On 11/20/25 1:40 PM, Catalin Marinas wrote: > On Thu, Nov 20, 2025 at 12:13:10PM -0800, Randy Dunlap wrote: >> On 11/20/25 11:29 AM, Conor Dooley wrote: >>> On Thu, Nov 20, 2025 at 05:30:46PM +0000, Catalin Marinas wrote: >>>> On Wed, Nov 19, 2025 at 07:08:27PM +0000, Conor Dooley wrote: >>>>> index 09aec4a1e13f..ac223e627bc5 100644 >>>>> --- a/lib/Kconfig >>>>> +++ b/lib/Kconfig >>>>> @@ -544,8 +544,9 @@ config ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION >>>>> bool >>>>> >>>>> config GENERIC_CPU_CACHE_MAINTENANCE >>>>> - bool >>>>> - select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION >>>>> + def_bool y >>>>> + depends on ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION >>>>> + depends on ARM64 >>>> >>>> That's what we do if GENERIC_CPU_CACHE_MAINTENANCE depends on some arch >>>> code but that's not the case here. GENERIC_CPU_CACHE_MAINTENANCE is an >>>> alternative implementation that an arch can select if it does not >>>> provide its own. I find the current code without the above patch better. >>> >>> Right, I am going to leave it as-is for now then. That's both you and I >>> (and presumably Jonathan) finding the current form more natural. Sorry >>> Randy! >> >> Thanks. I tried. >> >> I still say that it makes no sense for something generic >> (GENERIC_CPU_CACHE_MAINTENANCE in lib/Kconfig) to inform the >> config system that the config has something $ARCH-specific >> (ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION). > > Yes, that's not great either but the solution with the GENERIC depending > on ARCH does work since there's no actual dependency between them. > > As an alternative, I'm happy for arm64 to select both the ARCH and > GENERIC options if you think that works better. > Yes, I think that would be much better. Thanks. -- ~Randy
On Thu, 20 Nov 2025 15:25:46 -0800
Randy Dunlap <rdunlap@infradead.org> wrote:
> On 11/20/25 1:40 PM, Catalin Marinas wrote:
> > On Thu, Nov 20, 2025 at 12:13:10PM -0800, Randy Dunlap wrote:
> >> On 11/20/25 11:29 AM, Conor Dooley wrote:
> >>> On Thu, Nov 20, 2025 at 05:30:46PM +0000, Catalin Marinas wrote:
> >>>> On Wed, Nov 19, 2025 at 07:08:27PM +0000, Conor Dooley wrote:
> >>>>> index 09aec4a1e13f..ac223e627bc5 100644
> >>>>> --- a/lib/Kconfig
> >>>>> +++ b/lib/Kconfig
> >>>>> @@ -544,8 +544,9 @@ config ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
> >>>>> bool
> >>>>>
> >>>>> config GENERIC_CPU_CACHE_MAINTENANCE
> >>>>> - bool
> >>>>> - select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
> >>>>> + def_bool y
> >>>>> + depends on ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
> >>>>> + depends on ARM64
> >>>>
> >>>> That's what we do if GENERIC_CPU_CACHE_MAINTENANCE depends on some arch
> >>>> code but that's not the case here. GENERIC_CPU_CACHE_MAINTENANCE is an
> >>>> alternative implementation that an arch can select if it does not
> >>>> provide its own. I find the current code without the above patch better.
> >>>
> >>> Right, I am going to leave it as-is for now then. That's both you and I
> >>> (and presumably Jonathan) finding the current form more natural. Sorry
> >>> Randy!
> >>
> >> Thanks. I tried.
> >>
> >> I still say that it makes no sense for something generic
> >> (GENERIC_CPU_CACHE_MAINTENANCE in lib/Kconfig) to inform the
> >> config system that the config has something $ARCH-specific
> >> (ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION).
> >
> > Yes, that's not great either but the solution with the GENERIC depending
> > on ARCH does work since there's no actual dependency between them.
> >
> > As an alternative, I'm happy for arm64 to select both the ARCH and
> > GENERIC options if you think that works better.
> >
>
> Yes, I think that would be much better.
> Thanks.
>
I'm fine with that as well (was where we were in earlier versions).
I'm offline for 10 days from tomorrow, but wangyushan +CC has been heavily
involved in this series throughout if we need to test anything etc.
For a patch that is basically just (this to me seems fine to squash
as well if that is easier)
Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com>
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 893e0af0bc51..b4507eeabc4c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -20,6 +20,7 @@ config ARM64
select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
select ARCH_HAS_CACHE_LINE_SIZE
+ select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
select ARCH_HAS_CC_PLATFORM
select ARCH_HAS_CURRENT_STACK_POINTER
select ARCH_HAS_DEBUG_VIRTUAL
diff --git a/lib/Kconfig b/lib/Kconfig
index e11136d188ae..2923924bea78 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -544,7 +544,6 @@ config ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
config GENERIC_CPU_CACHE_MAINTENANCE
bool
- select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
config ARCH_HAS_MEMREMAP_COMPAT_ALIGN
bool
If not I'm guessing no one will mind too much if we tidy this up post or
late in merge window.
Thanks,
Jonathan
On Fri, Nov 21, 2025 at 10:48:27AM +0000, Jonathan Cameron wrote: > On Thu, 20 Nov 2025 15:25:46 -0800 > Randy Dunlap <rdunlap@infradead.org> wrote: > > On 11/20/25 1:40 PM, Catalin Marinas wrote: > > > As an alternative, I'm happy for arm64 to select both the ARCH and > > > GENERIC options if you think that works better. > > > > > > > Yes, I think that would be much better. > > Thanks. > > > > I'm fine with that as well (was where we were in earlier versions). > I'm offline for 10 days from tomorrow, but wangyushan +CC has been heavily > involved in this series throughout if we need to test anything etc. > > For a patch that is basically just (this to me seems fine to squash > as well if that is easier) Right, 3 votes for both, so I squashed that in. Thanks guys.
On 11/19/25 11:08 AM, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > Randy pointed out that the newly added GENERIC_CPU_CACHE_MAINTENANCE > was unusual, in that it selected an ARCH_HAS_... option, unlikely > anything else in lib/Kconfig. Switch things around, so that arm64 > selects ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION and then > GENERIC_CPU_CACHE_MAINENANCE will in turn be automatically enabled. > > Suggested-by: Randy Dunlap <rdunlap@infradead.org> > Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > --- > Catalin, you voiced a take on this already apparently that lead to the > current implementation so I'd like an ack from you or Will here. > My comment on the original thread, in response to Randy saying it was > backwards, that accompanied the diff was: > Maybe it is backwards, but I feel like this way is more logical. ARM64 > has memregion invalidation only because this generic approach is > enabled, so the arch selects what it needs to get the support. > Alternatively, something like (diff was here) implies (to me at least) > that arm64 has memregion invalidation as an architectural feature and > that the GENERIC_CPU_CACHE_MAINTENANCE option is a just common > cross-arch code, like generic entry etc, rather than being the option > gating the drivers that provide the feature in the first place. > Ultimately, the .config produced is the same either way, just depends on > what impression you want to give in the arch Kconfig, which might not > really be a big deal, just semantics. Either way, I'd like an ack :) > > Cheers, > Conor. > > CC: Catalin Marinas <catalin.marinas@arm.com> > CC: Will Deacon <will@kernel.org> > CC: linux-arm-kernel@lists.infradead.org > CC: linux-kernel@vger.kernel.org Acked-by: Randy Dunlap <rdunlap@infradead.org> Thanks. > --- > arch/arm64/Kconfig | 2 +- > lib/Kconfig | 5 +++-- > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 5f7f63d24931..75b2507f7eb2 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -21,6 +21,7 @@ config ARM64 > select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE > select ARCH_HAS_CACHE_LINE_SIZE > select ARCH_HAS_CC_PLATFORM > + select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > select ARCH_HAS_CURRENT_STACK_POINTER > select ARCH_HAS_DEBUG_VIRTUAL > select ARCH_HAS_DEBUG_VM_PGTABLE > @@ -146,7 +147,6 @@ config ARM64 > select GENERIC_ARCH_TOPOLOGY > select GENERIC_CLOCKEVENTS_BROADCAST > select GENERIC_CPU_AUTOPROBE > - select GENERIC_CPU_CACHE_MAINTENANCE > select GENERIC_CPU_DEVICES > select GENERIC_CPU_VULNERABILITIES > select GENERIC_EARLY_IOREMAP > diff --git a/lib/Kconfig b/lib/Kconfig > index 09aec4a1e13f..ac223e627bc5 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -544,8 +544,9 @@ config ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > bool > > config GENERIC_CPU_CACHE_MAINTENANCE > - bool > - select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > + def_bool y > + depends on ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION > + depends on ARM64 > > config ARCH_HAS_MEMREMAP_COMPAT_ALIGN > bool -- ~Randy
© 2016 - 2025 Red Hat, Inc.