[PATCH v2 00/10] x86: Kconfig cleanups and help text improvements

[PATCH v2 00/10] x86: Kconfig cleanups and help text improvements

[Mateusz Jończyk]

Hello,

There are some problems with Kconfig help texts in the kernel. They are
frequently confusing and use language that is difficult to understand
for people unfamiliar with the feature. Sometimes, the help text was not
updated after important kernel or ecosystem changes. References to
something "future" or "old" are also usually given without specifying
any dates.

First version of this patch series was sent out in February 2022.

Greetings,
Mateusz

Mateusz Jończyk (10):
  x86/Kconfig: enable X86_X2APIC by default and improve help text
  x86/apic: fix panic message when x2APIC is not supported
  x86/Kconfig: always enable ARCH_SPARSEMEM_ENABLE
  x86/Kconfig: drop X86_32_NON_STANDARD
  x86/Kconfig: move all X86_EXTENDED_PLATFORM options together
  x86/Kconfig: update lists in X86_EXTENDED_PLATFORM
  x86/Kconfig: document CONFIG_PCI_MMCONFIG
  x86/Kconfig: make CONFIG_PCI_CNB20LE_QUIRK depend on X86_32
  x86/Kconfig: document release year of glibc 2.3.3
  x86/Kconfig: remove CONFIG_ISA_BUS

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org

 arch/x86/Kconfig            | 136 ++++++++++++++++++++----------------
 arch/x86/kernel/apic/apic.c |   2 +-
 drivers/iio/dac/Kconfig     |   2 +-
 3 files changed, 76 insertions(+), 64 deletions(-)


base-commit: 7e18e42e4b280c85b76967a9106a13ca61c16179
-- 
2.25.1

[PATCH v2 01/10] x86/Kconfig: enable X86_X2APIC by default and improve help text

[Mateusz Jończyk]

As many current platforms (most modern Intel CPUs and QEMU) have x2APIC
present, enable CONFIG_X86_X2APIC by default as it gives performance
and functionality benefits. Additionally, if the BIOS has already
switched APIC to x2APIC mode, but CONFIG_X86_X2APIC is disabled, the
kernel will panic in arch/x86/kernel/apic/apic.c .

Also improve the help text, which was confusing and really did not
describe what the feature is about.

Help text references and discussion:

Both Intel [1] and AMD [3] spell the name as "x2APIC", not "x2apic".

"It allows faster access to the local APIC"
        [2], chapter 2.1, page 15:
        "More efficient MSR interface to access APIC registers."

"x2APIC was introduced in Intel CPUs around 2008":
        I was unable to find specific information which Intel CPUs
        support x2APIC. Wikipedia claims it was "introduced with the
        Nehalem microarchitecture in November 2008", but I was not able
        to confirm this independently. At least some Nehalem CPUs do not
        support x2APIC [1].

        The documentation [2] is dated June 2008. Linux kernel also
        introduced x2APIC support in 2008, so the year seems to be
        right.

"and in AMD EPYC CPUs in 2019":
        [3], page 15:
        "AMD introduced an x2APIC in our EPYC 7002 Series processors for
        the first time."

"It is also frequently emulated in virtual machines, even when the host
CPU does not support it."
        [1]

"If this configuration option is disabled, the kernel will not boot on
some platforms that have x2APIC enabled."
        According to some BIOS documentation [4], the x2APIC may be
        "disabled", "enabled", or "force enabled" on this system.
        I think that "enabled" means "made available to the operating
        system, but not already turned on" and "force enabled" means
        "already switched to x2APIC mode when the OS boots". Only in the
        latter mode a kernel without CONFIG_X86_X2APIC will panic in
        validate_x2apic() in arch/x86/kernel/apic/apic.c .

	QEMU 4.2.1 and my Intel HP laptop (bought in 2019) use the
	"enabled" mode and the kernel does not panic.

[1] "Re: [Qemu-devel] [Question] why x2apic's set by default without host sup"
        https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03527.html

[2] Intel® 64 Architecture x2APIC Specification,
        ( https://www.naic.edu/~phil/software/intel/318148.pdf )

[3] Workload Tuning Guide for AMD EPYC ™ 7002 Series Processor Based
        Servers Application Note,
        https://developer.amd.com/wp-content/resources/56745_0.80.pdf

[4] UEFI System Utilities and Shell Command Mobile Help for HPE ProLiant
        Gen10, ProLiant Gen10 Plus Servers and HPE Synergy:
        Enabling or disabling Processor x2APIC Support
        https://techlibrary.hpe.com/docs/iss/proliant-gen10-uefi/s_enable_disable_x2APIC_support.html

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>

---
v2: language fixes by Mr Randy Dunlap, change option name
---
 arch/x86/Kconfig | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f9920f1341c8..28133b5d3f12 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -440,15 +440,27 @@ config X86_FEATURE_NAMES
 	  If in doubt, say Y.
 
 config X86_X2APIC
-	bool "Support x2apic"
+	bool "x2APIC interrupt controller architecture support"
 	depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
+	default y
 	help
-	  This enables x2apic support on CPUs that have this feature.
+	  x2APIC is an interrupt controller architecture, a component of which
+	  (the local APIC) is present in the CPU. It allows faster access to
+	  the local APIC and supports a larger number of CPUs in the system
+	  than the predecessors.
 
-	  This allows 32-bit apic IDs (so it can support very large systems),
-	  and accesses the local apic via MSRs not via mmio.
+	  x2APIC was introduced in Intel CPUs around 2008 and in AMD EPYC CPUs
+	  in 2019, but it can be disabled by the BIOS. It is also frequently
+	  emulated in virtual machines, even when the host CPU does not support
+	  it. Support in the CPU can be checked by executing
+		cat /proc/cpuinfo | grep x2apic
 
-	  If you don't know what to do here, say N.
+	  If this configuration option is disabled, the kernel will not boot on
+	  some platforms that have x2APIC enabled.
+
+	  Say N if you know that your platform does not have x2APIC.
+
+	  Otherwise, say Y.
 
 config X86_MPPARSE
 	bool "Enable MPS table" if ACPI
-- 
2.25.1

Re: [PATCH v2 01/10] x86/Kconfig: enable X86_X2APIC by default and improve help text

[Borislav Petkov]

On Sun, Sep 11, 2022 at 10:47:02AM +0200, Mateusz Jończyk wrote:
> As many current platforms (most modern Intel CPUs and QEMU) have x2APIC
> present, enable CONFIG_X86_X2APIC by default as it gives performance
> and functionality benefits.

Can we do that without any detriment to older systems which don't have
x2APIC?

It looks so from a quick look...

> Additionally, if the BIOS has already
> switched APIC to x2APIC mode, but CONFIG_X86_X2APIC is disabled, the
> kernel will panic in arch/x86/kernel/apic/apic.c .
> 
> Also improve the help text, which was confusing and really did not
> describe what the feature is about.
> 
> Help text references and discussion:

So I'm not sure this discussion should be part of the commit message.

You can put it under the "---" line of the patch though.

> 
> Both Intel [1] and AMD [3] spell the name as "x2APIC", not "x2apic".
> 
> "It allows faster access to the local APIC"
>         [2], chapter 2.1, page 15:
>         "More efficient MSR interface to access APIC registers."
> 
> "x2APIC was introduced in Intel CPUs around 2008":
>         I was unable to find specific information which Intel CPUs
>         support x2APIC. Wikipedia claims it was "introduced with the
>         Nehalem microarchitecture in November 2008", but I was not able
>         to confirm this independently. At least some Nehalem CPUs do not
>         support x2APIC [1].
> 
>         The documentation [2] is dated June 2008. Linux kernel also
>         introduced x2APIC support in 2008, so the year seems to be
>         right.
> 
> "and in AMD EPYC CPUs in 2019":
>         [3], page 15:
>         "AMD introduced an x2APIC in our EPYC 7002 Series processors for
>         the first time."
> 
> "It is also frequently emulated in virtual machines, even when the host
> CPU does not support it."
>         [1]
> 
> "If this configuration option is disabled, the kernel will not boot on
> some platforms that have x2APIC enabled."
>         According to some BIOS documentation [4], the x2APIC may be
>         "disabled", "enabled", or "force enabled" on this system.
>         I think that "enabled" means "made available to the operating
>         system, but not already turned on" and "force enabled" means
>         "already switched to x2APIC mode when the OS boots". Only in the
>         latter mode a kernel without CONFIG_X86_X2APIC will panic in
>         validate_x2apic() in arch/x86/kernel/apic/apic.c .
> 
> 	QEMU 4.2.1 and my Intel HP laptop (bought in 2019) use the
> 	"enabled" mode and the kernel does not panic.
> 
> [1] "Re: [Qemu-devel] [Question] why x2apic's set by default without host sup"
>         https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03527.html
> 
> [2] Intel® 64 Architecture x2APIC Specification,
>         ( https://www.naic.edu/~phil/software/intel/318148.pdf )
> 
> [3] Workload Tuning Guide for AMD EPYC ™ 7002 Series Processor Based
>         Servers Application Note,
>         https://developer.amd.com/wp-content/resources/56745_0.80.pdf
> 
> [4] UEFI System Utilities and Shell Command Mobile Help for HPE ProLiant
>         Gen10, ProLiant Gen10 Plus Servers and HPE Synergy:
>         Enabling or disabling Processor x2APIC Support
>         https://techlibrary.hpe.com/docs/iss/proliant-gen10-uefi/s_enable_disable_x2APIC_support.html
> 
> Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Yinghai Lu <yinghai@kernel.org>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> 
> ---
> v2: language fixes by Mr Randy Dunlap, change option name
> ---
>  arch/x86/Kconfig | 22 +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f9920f1341c8..28133b5d3f12 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -440,15 +440,27 @@ config X86_FEATURE_NAMES
>  	  If in doubt, say Y.
>  
>  config X86_X2APIC
> -	bool "Support x2apic"
> +	bool "x2APIC interrupt controller architecture support"

s/architecture //g

and below too. Keep it simple pls.

>  	depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
> +	default y
>  	help
> -	  This enables x2apic support on CPUs that have this feature.
> +	  x2APIC is an interrupt controller architecture, a component of which
> +	  (the local APIC) is present in the CPU. It allows faster access to
> +	  the local APIC and supports a larger number of CPUs in the system
> +	  than the predecessors.
>  
> -	  This allows 32-bit apic IDs (so it can support very large systems),
> -	  and accesses the local apic via MSRs not via mmio.
> +	  x2APIC was introduced in Intel CPUs around 2008 and in AMD EPYC CPUs
> +	  in 2019, but it can be disabled by the BIOS. It is also frequently
> +	  emulated in virtual machines, even when the host CPU does not support
> +	  it. Support in the CPU can be checked by executing
> +		cat /proc/cpuinfo | grep x2apic

or simply

$ grep x2apic /proc/cpuinfo

>  
> -	  If you don't know what to do here, say N.
> +	  If this configuration option is disabled, the kernel will not boot on
> +	  some platforms that have x2APIC enabled.
> +
> +	  Say N if you know that your platform does not have x2APIC.

Does it matter?

If the platform doesn't support it, it'll fallback to APIC anyway.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v2 01/10] x86/Kconfig: enable X86_X2APIC by default and improve help text

[Thomas Gleixner]

On Wed, Oct 26 2022 at 20:38, Borislav Petkov wrote:
> On Sun, Sep 11, 2022 at 10:47:02AM +0200, Mateusz Jończyk wrote:
>> As many current platforms (most modern Intel CPUs and QEMU) have x2APIC
>> present, enable CONFIG_X86_X2APIC by default as it gives performance
>> and functionality benefits.
>
> Can we do that without any detriment to older systems which don't have
> x2APIC?

Can we please adjust to reality and do:

    X86_X2APIC
    bool
    default y if X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)

There is zero reason for having a knob.

Thanks,

        tglx

RE: [PATCH v2 01/10] x86/Kconfig: enable X86_X2APIC by default and improve help text

[Elliott, Robert (Servers)]

> As many current platforms (most modern Intel CPUs and QEMU) have x2APIC
> present, enable CONFIG_X86_X2APIC by default as it gives performance
> and functionality benefits. Additionally, if the BIOS has already
> switched APIC to x2APIC mode, but CONFIG_X86_X2APIC is disabled, the
> kernel will panic in arch/x86/kernel/apic/apic.c .
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> @@ -440,15 +440,27 @@ config X86_FEATURE_NAMES
>  	  If in doubt, say Y.
> 
>  config X86_X2APIC
> -	bool "Support x2apic"
> +	bool "x2APIC interrupt controller architecture support"
>  	depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP ||
> HYPERVISOR_GUEST)
> +	default y

Could this option be added to
	arch/x86/configs/x86_64_defconfig

so defconfig builds don't crash on current platforms?

Re: [PATCH v2 01/10] x86/Kconfig: enable X86_X2APIC by default and improve help text

[Dave Hansen]

On 10/27/22 07:45, Elliott, Robert (Servers) wrote:
>>  config X86_X2APIC
>> -	bool "Support x2apic"
>> +	bool "x2APIC interrupt controller architecture support"
>>  	depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP ||
>> HYPERVISOR_GUEST)
>> +	default y
> Could this option be added to
> 	arch/x86/configs/x86_64_defconfig
> 
> so defconfig builds don't crash on current platforms?

Sounds reasonable.  Care to send a patch?

RE: [PATCH v2 01/10] x86/Kconfig: enable X86_X2APIC by default and improve help text

[Elliott, Robert (Servers)]

> -----Original Message-----
> From: Dave Hansen <dave.hansen@intel.com>
> Sent: Thursday, October 27, 2022 10:08 AM
...
> Subject: Re: [PATCH v2 01/10] x86/Kconfig: enable X86_X2APIC by default
> and improve help text
> 
> On 10/27/22 07:45, Elliott, Robert (Servers) wrote:
> >>  config X86_X2APIC
> >> -	bool "Support x2apic"
> >> +	bool "x2APIC interrupt controller architecture support"
> >>  	depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP ||
> >> HYPERVISOR_GUEST)
> >> +	default y
> > Could this option be added to
> > 	arch/x86/configs/x86_64_defconfig
> >
> > so defconfig builds don't crash on current platforms?
> 
> Sounds reasonable.  Care to send a patch?

How are the defconfig files supposed to keep up with valid
combinations of options?

arch/x86/Kconfig has this set of dependencies:
  config X86_X2APIC
        bool "Support x2apic"
        depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)

  config X86_LOCAL_APIC
        def_bool y
        depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI
        select IRQ_DOMAIN_HIERARCHY
        select PCI_MSI_IRQ_DOMAIN if PCI_MSI

  config X86_IO_APIC
        def_bool y
        depends on X86_LOCAL_APIC || X86_UP_IOAPIC

drivers/iommu/Kconfig has:
  config IRQ_REMAP
        bool "Support for Interrupt Remapping"
        depends on X86_64 && X86_IO_APIC && PCI_MSI && ACPI
        select DMAR_TABLE

Despite its filename, arch/x86/configs/x86_64_defconfig does not even have:
  CONFIG_X86_64=y
which enables many options. That was added by:
  commit 622e3f28e50f ("x86: 64-bit defconfig remake")
  Sun May 4 19:57:19 2008 +0400 
but removed by:
  commit 8b1bb90701f9a51f ("defconfig reduction")
  Sat Aug 14 22:05:58 2010 +0200

It does have
  CONFIG_SMP=y

which should imply X86_LOCAL_APIC, but that's missing too.

It does have 
  CONFIG_HYPERVISOR_GUEST=y
so doesn't need IRQ_REMAP to enable X86_X2APIC.

Re: [PATCH v2 01/10] x86/Kconfig: enable X86_X2APIC by default and improve help text

[Dave Hansen]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

On 11/3/22 16:41, Elliott, Robert (Servers) wrote:
> How are the defconfig files supposed to keep up with valid
> combinations of options?

On some level, it doesn't matter as long as "make defconfig" and the
Kconfig rules result in something generally sane.

> Despite its filename, arch/x86/configs/x86_64_defconfig does not even have:
>   CONFIG_X86_64=y
> which enables many options. That was added by:
>   commit 622e3f28e50f ("x86: 64-bit defconfig remake")
>   Sun May 4 19:57:19 2008 +0400 
> but removed by:
>   commit 8b1bb90701f9a51f ("defconfig reduction")
>   Sat Aug 14 22:05:58 2010 +0200
> 
> It does have
>   CONFIG_SMP=y
> 
> which should imply X86_LOCAL_APIC, but that's missing too.
> 
> It does have 
>   CONFIG_HYPERVISOR_GUEST=y
> so doesn't need IRQ_REMAP to enable X86_X2APIC.

It sounds like folks generally want the defconfig files to have minimal
contents.  CONFIG_X86_64 isn't in there because it's not _needed_.

So, if the attached patch results in:

$ rm .config
$ make defconfig
$ grep X86_X2APIC .config
CONFIG_X86_X2APIC=y

Is there really anything else we need?  Kconfig seems to have figured
everything out just fine and without any complaints.

[-- Attachment #2: x64-defconfig.patch --]
[-- Type: text/x-patch, Size: 411 bytes --]

diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig
index 69784505a7a8..8cccda2a89c9 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -30,6 +30,7 @@ CONFIG_KALLSYMS_ALL=y
 CONFIG_PROFILING=y
 CONFIG_SMP=y
 CONFIG_HYPERVISOR_GUEST=y
+CONFIG_X86_X2APIC=y
 CONFIG_PARAVIRT=y
 CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
 CONFIG_MICROCODE_AMD=y

Re: [PATCH v2 01/10] x86/Kconfig: enable X86_X2APIC by default and improve help text

[David Heidelberg]

Hello Mat,

any chance you would incorporate feedback and respin the series or/and 
at least X2APIC parts?
For recent HW it becoming really necessary to have this option enabled.

Thank you
David

-- 
David Heidelberg

Re: [PATCH v2 01/10] x86/Kconfig: enable X86_X2APIC by default and improve help text

[Mateusz Jończyk]

W dniu 2.02.2024 o 15:08, David Heidelberg pisze:
> Hello Mat,
>
> any chance you would incorporate feedback and respin the series or/and at least X2APIC parts?
> For recent HW it becoming really necessary to have this option enabled.
>
> Thank you
> David
>
Hello,

OK, I'll rebase, update and send the X2APIC patch. Can't give you an ETA though.

I have mostly gave up kernel development, but you keep me motivated.

Greetings,

Mateusz

Re: [PATCH v2 01/10] x86/Kconfig: enable X86_X2APIC by default and improve help text

[David Heidelberg]

Sure, thank you a lot!

David

On 15/02/2024 22:10, Mateusz Jończyk wrote:
> W dniu 2.02.2024 o 15:08, David Heidelberg pisze:
>> Hello Mat,
>>
>> any chance you would incorporate feedback and respin the series or/and at least X2APIC parts?
>> For recent HW it becoming really necessary to have this option enabled.
>>
>> Thank you
>> David
>>
> Hello,
>
> OK, I'll rebase, update and send the X2APIC patch. Can't give you an ETA though.
>
> I have mostly gave up kernel development, but you keep me motivated.
>
> Greetings,
>
> Mateusz
>
-- 
David Heidelberg

[PATCH v2 02/10] x86/apic: fix panic message when x2APIC is not supported

[Mateusz Jończyk]

The correct course of action is to enable x2APIC support in the kernel,
not to disable it in the BIOS (which may be impossible).
x2APIC has performance and functionality benefits, so it is best to use
it if it is available on the platform.

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Johan Hovold <johan@kernel.org>
Cc: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Yinghai Lu <yinghai@kernel.org>
---
v2: add a newline at the end of the text

 arch/x86/kernel/apic/apic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 6d303d1d276c..206a2693a27a 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1902,7 +1902,7 @@ static int __init validate_x2apic(void)
 	/*
 	 * Checkme: Can we simply turn off x2apic here instead of panic?
 	 */
-	panic("BIOS has enabled x2apic but kernel doesn't support x2apic, please disable x2apic in BIOS.\n");
+	panic("Kernel does not support x2APIC, please recompile with CONFIG_X86_X2APIC or disable x2APIC in BIOS.\n");
 }
 early_initcall(validate_x2apic);
 
-- 
2.25.1

RE: [PATCH v2 02/10] x86/apic: fix panic message when x2APIC is not supported

[Elliott, Robert (Servers)]

> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
...
> @@ -1902,7 +1902,7 @@ static int __init validate_x2apic(void)
>  	/*
>  	 * Checkme: Can we simply turn off x2apic here instead of panic?
>  	 */
> -	panic("BIOS has enabled x2apic but kernel doesn't support x2apic, please disable x2apic in BIOS.\n");
> +	panic("Kernel does not support x2APIC, please recompile with CONFIG_X86_X2APIC or disable x2APIC in BIOS.\n");

With a defconfig build (no CONFIG_X86_X2APIC) on a system with x2apic,
I noticed this triggers before ever getting to that panic() call:

    static void setup_local_APIC(void)
    ...
        /*
         * Double-check whether this APIC is really registered.
         * This is meaningless in clustered apic mode, so we skip it.
         */
        BUG_ON(!apic->apic_id_registered());

That was also reported in 2020:
    https://lkml.org/lkml/2020/2/21/1501

The BUG print is:
[    5.827523] APIC: Switch to symmetric I/O mode setup
[    5.832519] ------------[ cut here ]------------
[    5.837163] kernel BUG at arch/x86/kernel/apic/apic.c:1593!
[    5.842767] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[    5.848009] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0.0-rc1-14412-g34ab3d31f076 #1
[    5.855954] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 03/08/2022
[    5.864508] RIP: 0010:setup_local_APIC+0x3aa/0x3c0
[    5.869317] Code: 02 0f 85 ca fe ff ff 85 d2 7f 26 48 8b 05 be 4d 62 01 be 00 07 01 00 bf 50 03 00 00 48 8b 40 10 e8 ab 51 fb 00 e9 c9 fe ff ff <0f> 0b e8 df 5f cb 00 e9 45 7f c5 00 66 2e 0f 1f 84 00 00 00 00 00
[    5.888156] RSP: 0000:ffffffffa6403e90 EFLAGS: 00010246
[    5.893398] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[    5.900555] RDX: 0000000000000000 RSI: 00000000fffffeff RDI: 0000000000000020
[    5.907712] RBP: ffffa2837ffea180 R08: 00000000ffffdfff R09: 00000000ffffdfff
[    5.914870] R10: ffffffffa6455f20 R11: ffffffffa6455f20 R12: ffffa2837ffea1c9
[    5.922027] R13: 0000000000000000 R14: ffffffffa6414120 R15: 000000009f1597b0
[    5.929185] FS:  0000000000000000(0000) GS:ffffa252c0000000(0000) knlGS:0000000000000000
[    5.937304] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    5.943067] CR2: ffffa2837fdff000 CR3: 00000028d320c001 CR4: 00000000000606f0
[    5.950225] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    5.957385] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    5.964543] Call Trace:
[    5.966994]  <TASK>
[    5.969097]  ? _printk+0x63/0x7e
[    5.972338]  apic_intr_mode_init+0xde/0xfc
[    5.976448]  x86_late_time_init+0x1b/0x2f
[    5.980471]  start_kernel+0x5db/0x69b
[    5.984143]  secondary_startup_64_no_verify+0xe0/0xeb
[    5.989213]  </TASK>

[PATCH v2 03/10] x86/Kconfig: always enable ARCH_SPARSEMEM_ENABLE

[Mateusz Jończyk]

It appears that (X86_64 || X86_32) is always true on x86.

This logical OR directive was introduced in
commit 6ea3038648da ("arch/x86: remove depends on CONFIG_EXPERIMENTAL")
probably by a trivial mistake.

Fixes: 6ea3038648da ("arch/x86: remove depends on CONFIG_EXPERIMENTAL")
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
---
 arch/x86/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 28133b5d3f12..70bf4df73fa2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1625,7 +1625,6 @@ config ARCH_FLATMEM_ENABLE
 
 config ARCH_SPARSEMEM_ENABLE
 	def_bool y
-	depends on X86_64 || NUMA || X86_32 || X86_32_NON_STANDARD
 	select SPARSEMEM_STATIC if X86_32
 	select SPARSEMEM_VMEMMAP_ENABLE if X86_64
 
-- 
2.25.1

[PATCH v2 04/10] x86/Kconfig: drop X86_32_NON_STANDARD

[Mateusz Jończyk]

This patch drops the "Support non-standard 32-bit SMP architectures"
configuration option. Currently, the only such an architecture is
STA2X11, so this option is useless. STA2X11 could now be selected
independently.

The dependency of X86_BIGSMP on X86_32_NON_STANDARD was dropped in
2009, in
commit 26f7ef14a76b ("x86: don't treat bigsmp as non-standard")
but the help text for X86_32_NON_STANDARD was not updated since.

CONFIG_X86_32_NON_STANDARD was used only in arch/x86/Kconfig, so it
could be dropped easily.

X86_32_NON_STANDARD depended on SMP, so
        (!SMP && !X86_32_NON_STANDARD) == !SMP
and
        (SMP || X86_32_NON_STANDARD) == SMP

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
---
 arch/x86/Kconfig | 19 ++++---------------
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 70bf4df73fa2..28f0c32fc65a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -706,18 +706,6 @@ config X86_RDC321X
 	  as R-8610-(G).
 	  If you don't have one of these chips, you should say N here.
 
-config X86_32_NON_STANDARD
-	bool "Support non-standard 32-bit SMP architectures"
-	depends on X86_32 && SMP
-	depends on X86_EXTENDED_PLATFORM
-	help
-	  This option compiles in the bigsmp and STA2X11 default
-	  subarchitectures.  It is intended for a generic binary
-	  kernel. If you select them all, kernel will probe it one by
-	  one and will fallback to default.
-
-# Alphabetically sorted list of Non standard 32 bit platforms
-
 config X86_SUPPORTS_MEMORY_FAILURE
 	def_bool y
 	# MCE code calls memory_failure():
@@ -729,7 +717,8 @@ config X86_SUPPORTS_MEMORY_FAILURE
 
 config STA2X11
 	bool "STA2X11 Companion Chip Support"
-	depends on X86_32_NON_STANDARD && PCI
+	depends on X86_32 && SMP
+	depends on X86_EXTENDED_PLATFORM && PCI
 	select SWIOTLB
 	select MFD_STA2X11
 	select GPIOLIB
@@ -1077,7 +1066,7 @@ config UP_LATE_INIT
 config X86_UP_APIC
 	bool "Local APIC support on uniprocessors" if !PCI_MSI
 	default PCI_MSI
-	depends on X86_32 && !SMP && !X86_32_NON_STANDARD
+	depends on X86_32 && !SMP
 	help
 	  A local APIC (Advanced Programmable Interrupt Controller) is an
 	  integrated interrupt controller in the CPU. If you have a single-CPU
@@ -1102,7 +1091,7 @@ config X86_UP_IOAPIC
 
 config X86_LOCAL_APIC
 	def_bool y
-	depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI
+	depends on X86_64 || SMP || X86_UP_APIC || PCI_MSI
 	select IRQ_DOMAIN_HIERARCHY
 	select PCI_MSI_IRQ_DOMAIN if PCI_MSI
 
-- 
2.25.1

[PATCH v2 05/10] x86/Kconfig: move all X86_EXTENDED_PLATFORM options together

[Mateusz Jończyk]

so that these options will be displayed together in menuconfig etc.

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
---
 arch/x86/Kconfig | 50 ++++++++++++++++++++++++------------------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 28f0c32fc65a..5a0bde075cae 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -642,6 +642,31 @@ config X86_INTEL_QUARK
 	  Say Y here if you have a Quark based system such as the Arduino
 	  compatible Intel Galileo.
 
+config X86_RDC321X
+	bool "RDC R-321x SoC"
+	depends on X86_32
+	depends on X86_EXTENDED_PLATFORM
+	select M486
+	select X86_REBOOTFIXUPS
+	help
+	  This option is needed for RDC R-321x system-on-chip, also known
+	  as R-8610-(G).
+	  If you don't have one of these chips, you should say N here.
+
+config STA2X11
+	bool "STA2X11 Companion Chip Support"
+	depends on X86_32 && SMP
+	depends on X86_EXTENDED_PLATFORM && PCI
+	select SWIOTLB
+	select MFD_STA2X11
+	select GPIOLIB
+	help
+	  This adds support for boards based on the STA2X11 IO-Hub,
+	  a.k.a. "ConneXt". The chip is used in place of the standard
+	  PC chipset, so all "standard" peripherals are missing. If this
+	  option is selected the kernel will still be able to boot on
+	  standard PC machines.
+
 config X86_INTEL_LPSS
 	bool "Intel Low Power Subsystem Support"
 	depends on X86 && ACPI && PCI
@@ -695,17 +720,6 @@ config IOSF_MBI_DEBUG
 
 	  If you don't require the option or are in doubt, say N.
 
-config X86_RDC321X
-	bool "RDC R-321x SoC"
-	depends on X86_32
-	depends on X86_EXTENDED_PLATFORM
-	select M486
-	select X86_REBOOTFIXUPS
-	help
-	  This option is needed for RDC R-321x system-on-chip, also known
-	  as R-8610-(G).
-	  If you don't have one of these chips, you should say N here.
-
 config X86_SUPPORTS_MEMORY_FAILURE
 	def_bool y
 	# MCE code calls memory_failure():
@@ -715,20 +729,6 @@ config X86_SUPPORTS_MEMORY_FAILURE
 	depends on X86_64 || !SPARSEMEM
 	select ARCH_SUPPORTS_MEMORY_FAILURE
 
-config STA2X11
-	bool "STA2X11 Companion Chip Support"
-	depends on X86_32 && SMP
-	depends on X86_EXTENDED_PLATFORM && PCI
-	select SWIOTLB
-	select MFD_STA2X11
-	select GPIOLIB
-	help
-	  This adds support for boards based on the STA2X11 IO-Hub,
-	  a.k.a. "ConneXt". The chip is used in place of the standard
-	  PC chipset, so all "standard" peripherals are missing. If this
-	  option is selected the kernel will still be able to boot on
-	  standard PC machines.
-
 config X86_32_IRIS
 	tristate "Eurobraille/Iris poweroff module"
 	depends on X86_32
-- 
2.25.1

[PATCH v2 06/10] x86/Kconfig: update lists in X86_EXTENDED_PLATFORM

[Mateusz Jończyk]

The order of the entries matches the order they appear in Kconfig.

In 2011, AMD Elan was moved to Kconfig.cpu and the dependency on
X86_EXTENDED_PLATFORM was dropped in
commit ce9c99af8d4b ("x86, cpu: Move AMD Elan Kconfig under "Processor family"")

Support for Moorestown MID devices was removed in 2012 in
commit 1a8359e411eb ("x86/mid: Remove Intel Moorestown")

SGI 320/540 (Visual Workstation) was removed in 2014 in
commit c5f9ee3d665a ("x86, platforms: Remove SGI Visual Workstation")

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
---
v2: update entries' order, 
    Goldfish is now "mostly Android emualator"

 arch/x86/Kconfig | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5a0bde075cae..31c2c574c67d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -512,12 +512,12 @@ config X86_EXTENDED_PLATFORM
 
 	  If you enable this option then you'll be able to select support
 	  for the following (non-PC) 32 bit x86 platforms:
-		Goldfish (Android emulator)
-		AMD Elan
+		Goldfish (mostly Android emulator)
+		Intel CE media processor (CE4100) SoC
+		Intel MID (Mobile Internet Device)
+		Intel Quark
 		RDC R-321x SoC
-		SGI 320/540 (Visual Workstation)
 		STA2X11-based (e.g. Northville)
-		Moorestown MID devices
 
 	  If you have one of these systems, or if you want to build a
 	  generic distribution kernel, say Y here - otherwise say N.
@@ -537,6 +537,8 @@ config X86_EXTENDED_PLATFORM
 		Numascale NumaChip
 		ScaleMP vSMP
 		SGI Ultraviolet
+		Goldfish (mostly Android emulator)
+		Intel MID (Mobile Internet Device)
 
 	  If you have one of these systems, or if you want to build a
 	  generic distribution kernel, say Y here - otherwise say N.
-- 
2.25.1

[PATCH v2 07/10] x86/Kconfig: document CONFIG_PCI_MMCONFIG

[Mateusz Jończyk]

This configuration option had no help text, so add it.

CONFIG_EXPERT is enabled on some distribution kernels, so people using a
distribution kernel's configuration as a starting point will see this
option.

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>

---
I would like someone to confirm that PCI Express is required for
MMCONFIG support.
---
 arch/x86/Kconfig | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 31c2c574c67d..fdfe8b7e895a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2712,6 +2712,19 @@ config PCI_MMCONFIG
 	default y
 	depends on PCI && (ACPI || JAILHOUSE_GUEST)
 	depends on X86_64 || (PCI_GOANY || PCI_GOMMCONFIG)
+	help
+	  Add support for accessing the PCI configuration space as a memory
+	  mapped area. It is the recommended method if the system supports
+	  this (it must have PCI Express and ACPI for it to be available).
+
+	  In the unlikely case that enabling this configuration option causes
+	  problems, the mechanism can be switched off with the 'pci=nommconf'
+	  command line parameter.
+
+	  Say 'n' only if you are sure that your platform does not support this
+	  access method or you have problems caused by it.
+
+	  Say 'y' otherwise.
 
 config PCI_OLPC
 	def_bool y
-- 
2.25.1

[PATCH v2 08/10] x86/Kconfig: make CONFIG_PCI_CNB20LE_QUIRK depend on X86_32

[Mateusz Jończyk]

I was unable to find a good description of the ServerWorks CNB20LE
chipset. However, it was probably exclusively used with the Pentium III
processor (this CPU model was used in all references to it that I
found where the CPU model was provided: dmesgs in [1] and [2];
[3] page 2; [4]-[7]).

As is widely known, the Pentium III processor did not support the 64-bit
mode, support for which was introduced by Intel a couple of years later.
So it is safe to assume that no systems with the CNB20LE chipset have
amd64 and the CONFIG_PCI_CNB20LE_QUIRK may now depend on X86_32.

Additionally, I have determined that most computers with the CNB20LE
chipset did have ACPI support and this driver was inactive on them.
I have submitted a patch to remove this driver, but it was met with
resistance [8].

[1] Jim Studt, Re: Problem with ServerWorks CNB20LE and lost interrupts
Linux Kernel Mailing List, https://lkml.org/lkml/2002/1/11/111

[2] RedHat Bug 665109 - e100 problems on old Compaq Proliant DL320
https://bugzilla.redhat.com/show_bug.cgi?id=665109

[3] R. Hughes-Jones, S. Dallison, G. Fairey, Performance Measurements on
Gigabit Ethernet NICs and Server Quality Motherboards,
http://datatag.web.cern.ch/papers/pfldnet2003-rhj.doc

[4] "Hardware for Linux",
Probe #d6b5151873 of Intel STL2-bd A28808-302 Desktop Computer (STL2)
https://linux-hardware.org/?probe=d6b5151873

[5] "Hardware for Linux", Probe #0b5d843f10 of Compaq ProLiant DL380
https://linux-hardware.org/?probe=0b5d843f10

[6] Ubuntu Forums, Dell Poweredge 2400 - Adaptec SCSI Bus AIC-7880
https://ubuntuforums.org/showthread.php?t=1689552

[7] Ira W. Snyder, "BISECTED: 2.6.35 (and -git) fail to boot: APIC problems"
https://lkml.org/lkml/2010/8/13/220

[8] Bjorn Helgaas, "Re: [PATCH] x86/pci: drop ServerWorks / Broadcom
CNB20LE PCI host bridge driver"
https://lore.kernel.org/lkml/20220318165535.GA840063@bhelgaas/T/

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ira W. Snyder <ira.snyder@gmail.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>
---
v2: make CONFIG_PCI_CNB20LE_QUIRK depend on X86_32
    (previously only help text and description were changed)
    upgrade short description.

 arch/x86/Kconfig | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index fdfe8b7e895a..31f778b0cd0b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2739,13 +2739,21 @@ config MMCONF_FAM10H
 	depends on X86_64 && PCI_MMCONFIG && ACPI
 
 config PCI_CNB20LE_QUIRK
-	bool "Read CNB20LE Host Bridge Windows" if EXPERT
-	depends on PCI
+	bool "Read PCI host bridge windows from the CNB20LE chipset" if EXPERT
+	depends on X86_32 && PCI
 	help
 	  Read the PCI windows out of the CNB20LE host bridge. This allows
 	  PCI hotplug to work on systems with the CNB20LE chipset which do
 	  not have ACPI.
 
+	  The ServerWorks (later Broadcom) CNB20LE was a chipset designed
+	  most probably only for Pentium III.
+
+	  To find out if you have such a chipset, search for a PCI device with
+	  1166:0009 PCI IDs, for example by executing
+		lspci -nn | grep '1166:0009'
+	  The code is inactive if there is none.
+
 	  There's no public spec for this chipset, and this functionality
 	  is known to be incomplete.
 
-- 
2.25.1

Re: [PATCH v2 08/10] x86/Kconfig: make CONFIG_PCI_CNB20LE_QUIRK depend on X86_32

[Bjorn Helgaas]

On Sun, Sep 11, 2022 at 10:47:09AM +0200, Mateusz Jończyk wrote:
> I was unable to find a good description of the ServerWorks CNB20LE
> chipset. However, it was probably exclusively used with the Pentium III
> processor (this CPU model was used in all references to it that I
> found where the CPU model was provided: dmesgs in [1] and [2];
> [3] page 2; [4]-[7]).
> 
> As is widely known, the Pentium III processor did not support the 64-bit
> mode, support for which was introduced by Intel a couple of years later.
> So it is safe to assume that no systems with the CNB20LE chipset have
> amd64 and the CONFIG_PCI_CNB20LE_QUIRK may now depend on X86_32.
> 
> Additionally, I have determined that most computers with the CNB20LE
> chipset did have ACPI support and this driver was inactive on them.
> I have submitted a patch to remove this driver, but it was met with
> resistance [8].

Only because removing the driver appeared to have no demonstrated
benefit and risked breaking old machines.

Making this depend on X86_32 seems plausible to me.

> [8] Bjorn Helgaas, "Re: [PATCH] x86/pci: drop ServerWorks / Broadcom
> CNB20LE PCI host bridge driver"
> https://lore.kernel.org/lkml/20220318165535.GA840063@bhelgaas/T/
> 
> Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Ira W. Snyder <ira.snyder@gmail.com>
> Cc: Bjorn Helgaas <helgaas@kernel.org>
> ---
> v2: make CONFIG_PCI_CNB20LE_QUIRK depend on X86_32
>     (previously only help text and description were changed)
>     upgrade short description.
> 
>  arch/x86/Kconfig | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index fdfe8b7e895a..31f778b0cd0b 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2739,13 +2739,21 @@ config MMCONF_FAM10H
>  	depends on X86_64 && PCI_MMCONFIG && ACPI
>  
>  config PCI_CNB20LE_QUIRK
> -	bool "Read CNB20LE Host Bridge Windows" if EXPERT
> -	depends on PCI
> +	bool "Read PCI host bridge windows from the CNB20LE chipset" if EXPERT
> +	depends on X86_32 && PCI
>  	help
>  	  Read the PCI windows out of the CNB20LE host bridge. This allows
>  	  PCI hotplug to work on systems with the CNB20LE chipset which do
>  	  not have ACPI.
>  
> +	  The ServerWorks (later Broadcom) CNB20LE was a chipset designed
> +	  most probably only for Pentium III.
> +
> +	  To find out if you have such a chipset, search for a PCI device with
> +	  1166:0009 PCI IDs, for example by executing
> +		lspci -nn | grep '1166:0009'
> +	  The code is inactive if there is none.
> +
>  	  There's no public spec for this chipset, and this functionality
>  	  is known to be incomplete.
>  
> -- 
> 2.25.1
> 

[PATCH v2 09/10] x86/Kconfig: document release year of glibc 2.3.3

[Mateusz Jończyk]

I wonder how many people were checking their glibc version when
considering whether to enable this option.

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
---
v2: shorten prompt.

 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 31f778b0cd0b..4612c356da4c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2278,7 +2278,7 @@ config DEBUG_HOTPLUG_CPU0
 
 config COMPAT_VDSO
 	def_bool n
-	prompt "Disable the 32-bit vDSO (needed for glibc 2.3.3)"
+	prompt "Workaround for glibc 2.3.2 / 2.3.3 (released in year 2003/2004)"
 	depends on COMPAT_32
 	help
 	  Certain buggy versions of glibc will crash if they are
-- 
2.25.1

[PATCH v2 10/10] x86/Kconfig: remove CONFIG_ISA_BUS

[Mateusz Jończyk]

CONFIG_ISA_BUS was used only as a dependency for a single Industrial IO
driver: CONFIG_CIO_DAC ("Measurement Computing CIO-DAC IIO driver"). At
least grepping the kernel source for "ISA_BUS" did not provide any other
meaningful results.

There are more configuration options that select CONFIG_ISA_BUS_API, but
did not depend on CONFIG_ISA_BUS. Most of these are for Industrial IO and
GPIO drivers.

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
v2: add "Acked by: William Breathitt Gray"

 arch/x86/Kconfig        | 11 -----------
 drivers/iio/dac/Kconfig |  2 +-
 2 files changed, 1 insertion(+), 12 deletions(-)


diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4612c356da4c..c8218d310d55 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2759,17 +2759,6 @@ config PCI_CNB20LE_QUIRK
 
 	  You should say N unless you know you need this.
 
-config ISA_BUS
-	bool "ISA bus support on modern systems" if EXPERT
-	help
-	  Expose ISA bus device drivers and options available for selection and
-	  configuration. Enable this option if your target machine has an ISA
-	  bus. ISA is an older system, displaced by PCI and newer bus
-	  architectures -- if your target machine is modern, it probably does
-	  not have an ISA bus.
-
-	  If unsure, say N.
-
 # x86_64 have no ISA slots, but can have ISA-style DMA.
 config ISA_DMA_API
 	bool "ISA-style DMA support" if (X86_64 && EXPERT)
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index 80521bd28d0f..e32245c013b0 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -275,7 +275,7 @@ config AD8801
 
 config CIO_DAC
 	tristate "Measurement Computing CIO-DAC IIO driver"
-	depends on X86 && (ISA_BUS || PC104)
+	depends on X86
 	select ISA_BUS_API
 	help
 	  Say yes here to build support for the Measurement Computing CIO-DAC
-- 
2.25.1