• Petr Mladek's avatar
    watchdog/hardlockup: sort hardlockup detector related config values a logical way · 4917a25f
    Petr Mladek authored
    Patch series "watchdog/hardlockup: Cleanup configuration of hardlockup
    detectors", v2.
    
    Clean up watchdog Kconfig after introducing the buddy detector.
    
    
    This patch (of 6):
    
    There are four possible variants of hardlockup detectors:
    
      + buddy: available when SMP is set.
    
      + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set.
    
      + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is set.
    
      + sparc64 special variant: available when HAVE_NMI_WATCHDOG is set
    	and HAVE_HARDLOCKUP_DETECTOR_ARCH is not set.
    
    Only one hardlockup detector can be compiled in. The selection is done
    using quite complex dependencies between several CONFIG variables.
    The following patches will try to make it more straightforward.
    
    As a first step, reorder the definitions of the various CONFIG variables.
    The logical order is:
    
       1. HAVE_* variables define available variants. They are typically
          defined in the arch/ config files.
    
       2. HARDLOCKUP_DETECTOR y/n variable defines whether the hardlockup
          detector is enabled at all.
    
       3. HARDLOCKUP_DETECTOR_PREFER_BUDDY y/n variable defines whether
          the buddy detector should be preferred over the perf one.
          Note that the arch specific variants are always preferred when
          available.
    
       4. HARDLOCKUP_DETECTOR_PERF/BUDDY variables define whether the given
          detector is enabled in the end.
    
       5. HAVE_HARDLOCKUP_DETECTOR_NON_ARCH and HARDLOCKUP_DETECTOR_NON_ARCH
          are temporary variables that are going to be removed in
          a followup patch.
    
    This is a preparation step for further cleanup. It will change the logic
    without shuffling the definitions.
    
    This change temporary breaks the C-like ordering where the variables are
    declared or defined before they are used. It is not really needed for
    Kconfig. Also the following patches will rework the logic so that
    the ordering will be C-like in the end.
    
    The patch just shuffles the definitions. It should not change the existing
    behavior.
    
    Link: https://lkml.kernel.org/r/20230616150618.6073-1-pmladek@suse.com
    Link: https://lkml.kernel.org/r/20230616150618.6073-2-pmladek@suse.comSigned-off-by: default avatarPetr Mladek <pmladek@suse.com>
    Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
    Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    4917a25f
Kconfig.debug 96.6 KB