On 15/11/23 5:46 pm, Aneesh Kumar K V wrote: > On 11/15/23 5:23 PM, Vishal Chourasia wrote: >> On 15/11/23 1:39 pm, Aneesh Kumar K.V wrote: >>> Vishal Chourasia <vish...@linux.ibm.com> writes: >>> >>>> This patch modifies the ARCH_HIBERNATION_POSSIBLE option to ensure that it >>>> correctly depends on these PowerPC configurations being enabled. As a >>>> result, >>>> it prevents the HOTPLUG_CPU from being selected when the required >>>> dependencies >>>> are not satisfied. >>>> >>>> This change aligns the dependency tree with the expected hardware support >>>> for >>>> CPU hot-plugging under PowerPC architectures, ensuring that the kernel >>>> configuration steps do not lead to inconsistent states. >>>> >>>> Signed-off-by: Vishal Chourasia <vish...@linux.ibm.com> >>>> --- >>>> During the configuration process with 'make randconfig' followed by >>>> 'make olddefconfig', we observed a warning indicating an unmet direct >>>> dependency for the HOTPLUG_CPU option. The dependency in question relates >>>> to >>>> various PowerPC configurations (PPC_PSERIES, PPC_PMAC, PPC_POWERNV, >>>> FSL_SOC_BOOKE) which were not enabled, yet the HOTPLUG_CPU was being >>>> erroneously selected due to an implicit assumption by the PM_SLEEP_SMP >>>> option. >>>> This misalignment in dependencies could potentially lead to inconsistent >>>> kernel >>>> configuration states, especially when considering the necessary hardware >>>> support for CPU hot-plugging on PowerPC platforms. The patch aims to >>>> correct >>>> this by ensuring that ARCH_HIBERNATION_POSSIBLE is contingent upon the >>>> appropriate PowerPC configurations being active. >>>> >>>> steps to reproduce (before applying the patch): >>>> >>>> Run 'make pseries_le_defconfig' >>>> Run 'make menuconfig' >>>> Enable hibernation [ Kernel options -> Hibernation (aka 'suspend to disk') >>>> ] >>>> Disable [ Platform support -> IBM PowerNV (Non-Virtualized) platform >>>> support ] >>>> Disable [ Platform support -> IBM pSeries & new (POWER5-based) iSeries ] >>>> Enable SMP [ Processor support -> Symmetric multi-processing support ] >>>> Save the config >>>> Run 'make olddefconfig' >>>> >>>> arch/powerpc/Kconfig | 5 +++-- >>>> 1 file changed, 3 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >>>> index 6f105ee4f3cf..bf99ff9869f6 100644 >>>> --- a/arch/powerpc/Kconfig >>>> +++ b/arch/powerpc/Kconfig >>>> @@ -380,8 +380,9 @@ config DEFAULT_UIMAGE >>>> Used to allow a board to specify it wants a uImage built by default >>>> >>>> config ARCH_HIBERNATION_POSSIBLE >>>> - bool >>>> - default y >>>> + def_bool y >>>> + depends on PPC_PSERIES || \ >>>> + PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE >>>> >>>> config ARCH_SUSPEND_POSSIBLE >>>> def_bool y >>>> >>> I am wondering whether it should be switched to using select from >>> config PPC? >>> >>> selecting ARCH_HIBERNATION_POSSIBLE based on value of config PPC >>> will not guarantee config PPC_PSERIES being set >>> >>> PPC_PSERIES can be set to N, even when config PPC is set. I understand what you meant before. Having ARCH_HIBERNATION_POSSIBLE under config PPC makes more sense. >>> grep -A 5 -i "config ppc_pseries" arch/powerpc/platforms/pseries/Kconfig >>> config PPC_PSERIES >>> depends on PPC64 && PPC_BOOK3S >>> bool "IBM pSeries & new (POWER5-based) iSeries" >>> select HAVE_PCSPKR_PLATFORM >>> select MPIC >>> select OF_DYNAMIC >>> > modified arch/powerpc/Kconfig > @@ -156,6 +156,7 @@ config PPC > select ARCH_HAS_UACCESS_FLUSHCACHE > select ARCH_HAS_UBSAN_SANITIZE_ALL > select ARCH_HAVE_NMI_SAFE_CMPXCHG > + select ARCH_HIBERNATION_POSSIBLE if (PPC_PSERIES || PPC_PMAC || > PPC_POWERNV || FSL_SOC_BOOKE) > select ARCH_KEEP_MEMBLOCK > select ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE if PPC_RADIX_MMU > select ARCH_MIGHT_HAVE_PC_PARPORT
Though, even with these changes I was able to reproduce same warnings. (using steps from above) It's because one can enable HIBERNATION manually. As these warnings were observed through make randconfig, there is still a chance that randconfig may result in a permutation that may produce these warnings again. > > -aneesh
