On Tue, Dec 23, 2025 at 10:26:12PM -0400, Jason Gunthorpe wrote: > On Fri, Dec 19, 2025 at 09:34:33PM +0100, Arnd Bergmann wrote: > > On Fri, Dec 19, 2025, at 18:14, Jason Gunthorpe wrote: > > > On Fri, Dec 19, 2025 at 05:15:58PM +0100, Arnd Bergmann wrote: > > >> arch/arm/Kconfig | 1 + > > >> arch/arm/configs/gemini_defconfig | 1 - > > >> arch/arm/configs/multi_v5_defconfig | 1 - > > >> arch/arm/configs/mvebu_v5_defconfig | 1 - > > >> arch/arm/include/asm/highmem.h | 56 ++--------------------------- > > >> arch/arm/mm/cache-feroceon-l2.c | 31 ++-------------- > > >> arch/arm/mm/cache-xsc3l2.c | 47 +++--------------------- > > >> arch/arm/mm/dma-mapping.c | 12 ++----- > > >> arch/arm/mm/flush.c | 19 +++------- > > >> 9 files changed, 16 insertions(+), 153 deletions(-) > > > > > > This looks great, but do you think there should be a boot time crash > > > if a VIVT and HIGHMEM are enabled, just incase? > > > > Do you mean in the common code or just for Arm? > > > > We could use the Arm specific cache_is_vivt() macro, but it feels like > > the 'dpends on !CPU_CACHE_VIVT' Kconfig check I added is both > > safer and simpler. > > Okay, so maybe I'm asking if !CPU_CACHE_VIVT then the kernel fails to > boot on vivt systems, maybe it already does?
The cache modes (CPU_CACHE_xxx) are (were) selected by the processor config entries. Not having the correct processor support built in to the kernel will cause a boot failure. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
