Commit 0231d00082f6 ("ACPI: SPCR: Make SPCR available to x86")
made SPCR available as an earlycon option on x86 but did not add
it as a preferred console to avoid breaking existing setups -
users have to round trip the dumped console options
("SPCR: console: uart,io,0x3f8,115200") back via their
bootloader.

Let users opt in so serial console configuration can be made
automatic.

Signed-off-by: Shenghao Yang <me@shenghaoyang.info>
---
 Documentation/admin-guide/kernel-parameters.txt | 2 ++
 arch/x86/kernel/acpi/boot.c                     | 7 ++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index a8d0afde7f85..f9c5b6e4eda9 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -125,6 +125,8 @@ Kernel parameters
 			may result in duplicate corrected error reports.
 			nospcr -- disable console in ACPI SPCR table as
 				default _serial_ console on ARM64
+			spcr -- enable console in ACPI SPCR table as
+				default _serial_ console on X86
 			For ARM64, ONLY "acpi=off", "acpi=on", "acpi=force" or
 			"acpi=nospcr" are available
 			For RISCV64, ONLY "acpi=off", "acpi=on" or "acpi=force"
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 9fa321a95eb3..83bbfa1d6f1f 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -47,6 +47,7 @@ EXPORT_SYMBOL(acpi_disabled);
 
 int acpi_noirq;				/* skip ACPI IRQ initialization */
 static int acpi_nobgrt;			/* skip ACPI BGRT */
+static int acpi_spcr_add __initdata;		/* add SPCR-provided console */
 int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
 EXPORT_SYMBOL(acpi_pci_disabled);
 
@@ -1666,7 +1667,7 @@ int __init acpi_boot_init(void)
 		x86_init.pci.init = pci_acpi_init;
 
 	/* Do not enable ACPI SPCR console by default */
-	acpi_parse_spcr(earlycon_acpi_spcr_enable, false);
+	acpi_parse_spcr(earlycon_acpi_spcr_enable, acpi_spcr_add);
 	return 0;
 }
 
@@ -1703,6 +1704,10 @@ static int __init parse_acpi(char *arg)
 	/* "acpi=nocmcff" disables FF mode for corrected errors */
 	else if (strcmp(arg, "nocmcff") == 0) {
 		acpi_disable_cmcff = 1;
+	}
+	/* "acpi=spcr" adds the SPCR-provided console as a preferred one */
+	else if (strcmp(arg, "spcr") == 0) {
+		acpi_spcr_add = 1;
 	} else {
 		/* Core will printk when we return error. */
 		return -EINVAL;
-- 
2.52.0

On Sun, Dec 28, 2025 at 05:22:22PM +0800, Shenghao Yang wrote:
> Commit 0231d00082f6 ("ACPI: SPCR: Make SPCR available to x86")
> made SPCR available as an earlycon option on x86 but did not add
> it as a preferred console to avoid breaking existing setups -

No one has noticed AFAICT since 2018 (this commit's date).

Also:

        /* Do not enable ACPI SPCR console by default */
        acpi_parse_spcr(earlycon_acpi_spcr_enable, false);

Looks nicely conservative to me.

> users have to round trip the dumped console options
> ("SPCR: console: uart,io,0x3f8,115200") back via their
> bootloader.

I don't know what that means.

> Let users opt in so serial console configuration can be made
> automatic.

Why?

Text says:

	[X86] When used with no options the early console is
	determined by the ACPI SPCR table.

But the code doesn't enable the SPCR console by default.

I have no clue what this patch is trying to do.

-- 
Regards/Gruss,
    Boris.

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

Hi,

On 14/1/26 23:46, Borislav Petkov wrote:
> On Sun, Dec 28, 2025 at 05:22:22PM +0800, Shenghao Yang wrote:
>> Commit 0231d00082f6 ("ACPI: SPCR: Make SPCR available to x86")
>> made SPCR available as an earlycon option on x86 but did not add
>> it as a preferred console to avoid breaking existing setups -
> 
> No one has noticed AFAICT since 2018 (this commit's date).
> 
> Also:
> 
>         /* Do not enable ACPI SPCR console by default */
>         acpi_parse_spcr(earlycon_acpi_spcr_enable, false);
> 
> Looks nicely conservative to me.
> 

Thanks for taking a look.

>> users have to round trip the dumped console options
>> ("SPCR: console: uart,io,0x3f8,115200") back via their
>> bootloader.
> 
> I don't know what that means.

The kernel decodes the SPCR table and dumps the settings to use
the firmware preferred console in the kernel log:

[    0.005091] ACPI: SPCR 0x000000007FFB5000 000059 (v04 ALASKA A M I    01072009 INTL 20250404)
[    0.073387] ACPI: SPCR: console: uart,io,0x3f8,115200

We've been inserting the dumped config into the kernel command 
line and rebooting on first boot (e.g. console=uart,io,0x3f8,115200),
but would love to avoid this loop.

> 
>> Let users opt in so serial console configuration can be made
>> automatic.
> 
> Why?

It's easier this way for larger fleets - we don't want to manage
hardware specific serial console settings on the kernel command line
if the firmware is already capable of telling us the correct ones.

> 
> Text says:
> 
> 	[X86] When used with no options the early console is
> 	determined by the ACPI SPCR table.
> 
> But the code doesn't enable the SPCR console by default.

If earlycon is specified on the command line the console from SPCR
is used, but only as a boot console. It's not present in
/proc/consoles.

It is possible to retain it with keep_bootcon, but that uses the
less efficient (in the 8250 case) 8250_early driver.

> 
> I have no clue what this patch is trying to do.
> 

In 0231d00082f6 ("ACPI: SPCR: Make SPCR available to x86") the SPCR
console is only added as an option for earlycon but not as an ordinary
console so users don't see console output changes.  

The patch adds an opt in so we can get the SPCR console added as
an ordinary console.

Thanks,

Shenghao

On Thu, Jan 15, 2026 at 01:09:40AM +0800, Shenghao Yang wrote:
> We've been inserting the dumped config into the kernel command 
> line and rebooting on first boot (e.g. console=uart,io,0x3f8,115200),
> but would love to avoid this loop.

Yah, put that in your v2 pls. That's much more understandable.

> It's easier this way for larger fleets - we don't want to manage
> hardware specific serial console settings on the kernel command line
> if the firmware is already capable of telling us the correct ones.

Should also be in the commit message.

> If earlycon is specified on the command line the console from SPCR
> is used, but only as a boot console. It's not present in
> /proc/consoles.
> 
> It is possible to retain it with keep_bootcon, but that uses the
> less efficient (in the 8250 case) 8250_early driver.

Also for the commit message.

> In 0231d00082f6 ("ACPI: SPCR: Make SPCR available to x86") the SPCR
> console is only added as an option for earlycon but not as an ordinary
> console so users don't see console output changes.  
> 
> The patch adds an opt in so we can get the SPCR console added as
> an ordinary console.

Yap, your explanations make much more sense, thanks.

Please structure your v2 something like this boilerplate guidance below:

1. Prepare the context for the explanation briefly.

2. Explain the problem at hand.

3. "It happens because of <...>"

4. "Fix it by doing X"

5. "(Potentially do Y)."

And some of those above are optional depending on the issue being
explained.

For more detailed info, see
Documentation/process/submitting-patches.rst,
Section "2) Describe your changes".

Also, to the tone, from Documentation/process/submitting-patches.rst:

 "Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
  instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
  to do frotz", as if you are giving orders to the codebase to change
  its behaviour."

Also, do not talk about what your patch does - that should (hopefully) be
visible from the diff itself. Rather, talk about *why* you're doing what
you're doing.

-- 
Regards/Gruss,
    Boris.

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

Hi,

On 15/1/26 20:00, Borislav Petkov wrote:
> On Thu, Jan 15, 2026 at 01:09:40AM +0800, Shenghao Yang wrote:
>> We've been inserting the dumped config into the kernel command 
>> line and rebooting on first boot (e.g. console=uart,io,0x3f8,115200),
>> but would love to avoid this loop.
> 
> Yah, put that in your v2 pls. That's much more understandable.
> 
>> It's easier this way for larger fleets - we don't want to manage
>> hardware specific serial console settings on the kernel command line
>> if the firmware is already capable of telling us the correct ones.
> 
> Should also be in the commit message.
> 
>> If earlycon is specified on the command line the console from SPCR
>> is used, but only as a boot console. It's not present in
>> /proc/consoles.
>>
>> It is possible to retain it with keep_bootcon, but that uses the
>> less efficient (in the 8250 case) 8250_early driver.
> 
> Also for the commit message.
> 
>> In 0231d00082f6 ("ACPI: SPCR: Make SPCR available to x86") the SPCR
>> console is only added as an option for earlycon but not as an ordinary
>> console so users don't see console output changes.  
>>
>> The patch adds an opt in so we can get the SPCR console added as
>> an ordinary console.
> 
> Yap, your explanations make much more sense, thanks.
> 
> Please structure your v2 something like this boilerplate guidance below:
> 
> 1. Prepare the context for the explanation briefly.
> 
> 2. Explain the problem at hand.
> 
> 3. "It happens because of <...>"
> 
> 4. "Fix it by doing X"
> 
> 5. "(Potentially do Y)."
> 
> And some of those above are optional depending on the issue being
> explained.
> 
> For more detailed info, see
> Documentation/process/submitting-patches.rst,
> Section "2) Describe your changes".
> 
> Also, to the tone, from Documentation/process/submitting-patches.rst:
> 
>  "Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
>   instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
>   to do frotz", as if you are giving orders to the codebase to change
>   its behaviour."
> 
> Also, do not talk about what your patch does - that should (hopefully) be
> visible from the diff itself. Rather, talk about *why* you're doing what
> you're doing.
> 

Thanks! I'll reword and send v2.

Shenghao