On Sun, Apr 18, 2021 at 12:35:12PM +0300, Mike Rapoport wrote: > From: Mike Rapoport <rppt@xxxxxxxxxxxxx> > > CAVIUM_OCTEON_SOC configuration selects HOLES_IN_ZONE option to cope with > memory crashes that were happening in 2011. > > This option effectively aliases pfn_valid_within() to pfn_valid() when > enabled and hardwires it to 1 when disabled. The check for > pfn_valid_within() is only relevant in case the memory map may have holes > or undefined struct page instances inside MAX_ORDER chunks. > > Since 2011 memory management initialization in general and memory map > initialization particularly became much more robust so the check for > pfn_valid_within() is not required on Octeon even despite its, hmm, unusual > memory setup. > > Remove the selection of HOLES_IN_ZONE by CAVIUM_OCTEON_SOC and drop the > HOLES_IN_ZONE configuration option entirely as Octeon was the only MIPS > platform to use it. > > Signed-off-by: Mike Rapoport <rppt@xxxxxxxxxxxxx> > --- > > Hi, > > I've tried to find why Octeon needed CONFIG_HOLES_IN_ZONE in the first > place, but there is nothing except the changelog in commit 465aaed0030b > ("MIPS: Octeon: Select CONFIG_HOLES_IN_ZONE"): > > Current Octeon systems do in fact have holes in their memory zones. > We need to select HOLES_IN_ZONE. If we do not, some memory configurations > will result in crashes at boot time > > Since then there were too many changes around memory management > initialization both in the generic mm and on the MIPS side to track what > exactly could case the crashes. > > I'm pretty confident that HOLES_IN_ZONE is not required for Octeon systems > anymore and can be removed. > > I'd really appreciate if somebody with access to an Octeon system could > test this patch. > > arch/mips/Kconfig | 4 ---- > 1 file changed, 4 deletions(-) applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]