console: Add console=auto option
Subsystems (5)
PATCH 1/1 console: Add console=auto option
ACPI may contain an SPCR table that defines a default system console. On ARM if the table is present then the SPCR console is enabled by default. On x86 the SPCR console is used if 'earlycon' (no parameters) is specified as a kernel parameter and is used only as the early console. To use the SPCR data as a console a user must boot with 'earlycon', grep logs & specify a console= kernel parameter, and then reboot again.
Add 'console=auto' that enables a firmware or hardware console, and on x86 enable the SPCR console if 'console=auto' is specified.
Tested on systems with and without an ACPI SPCR. The following kernel parameters were also tested:
console=ttyS0,115200 works earlycon works (early console only) console=auto works (full console as expected)
no console or earlycon arguments works (no output as expected)
--- Documentation/admin-guide/kernel-parameters.txt | 1 + arch/x86/kernel/acpi/boot.c | 5 +++++ include/linux/console.h | 1 + kernel/printk/printk.c | 10 ++++++++++ 4 files changed, 17 insertions(+)
Documentation/admin-guide/kernel-parameters.txt +1 -0
@@ -635,6 +635,7 @@ hvc<n> Use the hypervisor console device <n>. This is for both Xen and PowerPC hypervisors. + auto [X86] Enable ACPI SPCR console If the device connected to the port is not a TTY but a braille device, prepend "brl," before the device type, for instance
arch/x86/kernel/acpi/boot.c +5 -0
@@ -1771,3 +1771,8 @@ void __init arch_reserve_mem_area(acpi_physical_address addr, size_t size)e820__range_add (addr, size,E820_TYPE_ACPI );e820__update_table_print (); } + +void __init arch_console_setup (void ) +{ +acpi_parse_spcr (false, true); +}
include/linux/console.h +1 -0
@@ -181,6 +181,7 @@ extern int is_console_locked(void);extern int braille_register_console (struct console *,int index,char *console_options,char *braille_options);extern int braille_unregister_console (struct console *); +int arch_console_setup (void );#ifdef CONFIG_TTY extern void console_sysfs_notify (void );#else
kernel/printk/printk.c +10 -0
@@ -2078,6 +2078,11 @@ static int __init console_msg_format_setup(char *str) }__setup ("console_msg_format=" , console_msg_format_setup); +int __init __weak arch_console_setup (void ) +{ +return 0 ; +} +/* * Set up a console. Called via do_early_param() in init/main.c * for each "console=" parameter in the boot command line.
@@ -2088,6 +2093,11 @@ static int __init console_setup(char *str)char *s, *options, *brl_options =NULL ;int idx; +if (!strcmp (str,"auto" )) { +arch_console_setup (); +return 1 ; + } +if (_braille_console_setup (&str, &brl_options))return 1 ;
Signature · 1 line
2.14.4
Greg Kroah-Hartman
maintainerQuoted 63 lines · Prarit Bhargava
ACPI may contain an SPCR table that defines a default system console. On ARM if the table is present then the SPCR console is enabled by default. On x86 the SPCR console is used if 'earlycon' (no parameters) is specified as a kernel parameter and is used only as the early console. To use the SPCR data as a console a user must boot with 'earlycon', grep logs & specify a console= kernel parameter, and then reboot again.
Add 'console=auto' that enables a firmware or hardware console, and on x86 enable the SPCR console if 'console=auto' is specified.
Tested on systems with and without an ACPI SPCR. The following kernel parameters were also tested:
console=ttyS0,115200 works earlycon works (early console only) console=auto works (full console as expected)no console or earlycon arguments works (no output as expected)
Signed-off-by Prarit Bhargava <[email protected]>Cc Mark Salter <[email protected]>Cc Al Stone <[email protected]>Cc "Rafael J. Wysocki" <[email protected]>Cc Len Brown <[email protected]>Cc Pavel Machek <[email protected]>Cc Petr Mladek <[email protected]>Cc Sergey Senozhatsky <[email protected]>Cc Steven Rostedt <[email protected]>Cc Kees Cook <[email protected]>Cc Greg Kroah-Hartman <[email protected]>--- Documentation/admin-guide/kernel-parameters.txt | 1 + arch/x86/kernel/acpi/boot.c | 5 +++++ include/linux/console.h | 1 + kernel/printk/printk.c | 10 ++++++++++ 4 files changed, 17 insertions(+)Documentation/admin-guide/kernel-parameters.txt +1
-0@@ -635,6 +635,7 @@ hvc<n> Use the hypervisor console device <n>. This is for both Xen and PowerPC hypervisors. + auto [X86] Enable ACPI SPCR console If the device connected to the port is not a TTY but a braille device, prepend "brl," before the device type, for instancearch/x86/kernel/acpi/boot.c +5
-0@@ -1771,3 +1771,8 @@ void __init arch_reserve_mem_area(acpi_physical_address addr, size_t size)e820__range_add (addr, size,E820_TYPE_ACPI );e820__update_table_print (); } + +void __init arch_console_setup (void ) +{ +acpi_parse_spcr (false, true); +}
<snip>
Quoted 1 line
+int
arch_console_setup(void);
Function does not match its prototype :(
How did you build this successfully?
Quoted 67 lines · Greg Kroah-Hartman
Quoted 63 lines · Prarit Bhargava
ACPI may contain an SPCR table that defines a default system console. On ARM if the table is present then the SPCR console is enabled by default. On x86 the SPCR console is used if 'earlycon' (no parameters) is specified as a kernel parameter and is used only as the early console. To use the SPCR data as a console a user must boot with 'earlycon', grep logs & specify a console= kernel parameter, and then reboot again.
Add 'console=auto' that enables a firmware or hardware console, and on x86 enable the SPCR console if 'console=auto' is specified.
Tested on systems with and without an ACPI SPCR. The following kernel parameters were also tested:
console=ttyS0,115200 works earlycon works (early console only) console=auto works (full console as expected)no console or earlycon arguments works (no output as expected)
Signed-off-by Prarit Bhargava <[email protected]>Cc Mark Salter <[email protected]>Cc Al Stone <[email protected]>Cc "Rafael J. Wysocki" <[email protected]>Cc Len Brown <[email protected]>Cc Pavel Machek <[email protected]>Cc Petr Mladek <[email protected]>Cc Sergey Senozhatsky <[email protected]>Cc Steven Rostedt <[email protected]>Cc Kees Cook <[email protected]>Cc Greg Kroah-Hartman <[email protected]>--- Documentation/admin-guide/kernel-parameters.txt | 1 + arch/x86/kernel/acpi/boot.c | 5 +++++ include/linux/console.h | 1 + kernel/printk/printk.c | 10 ++++++++++ 4 files changed, 17 insertions(+)Documentation/admin-guide/kernel-parameters.txt +1
-0@@ -635,6 +635,7 @@ hvc<n> Use the hypervisor console device <n>. This is for both Xen and PowerPC hypervisors. + auto [X86] Enable ACPI SPCR console If the device connected to the port is not a TTY but a braille device, prepend "brl," before the device type, for instancearch/x86/kernel/acpi/boot.c +5
-0@@ -1771,3 +1771,8 @@ void __init arch_reserve_mem_area(acpi_physical_address addr, size_t size)e820__range_add (addr, size,E820_TYPE_ACPI );e820__update_table_print (); } + +void __init arch_console_setup (void ) +{ +acpi_parse_spcr (false, true); +}<snip>
Quoted 5 lines
Quoted 1 line
+int
arch_console_setup(void);Function does not match its prototype :(
How did you build this successfully?
Weird, it compiles on my system?
I'll fix it though.
P.
Quoted 1 line
Steven Rostedt
reviewerQuoted 68 lines · On Thu, 16 Aug 2018 11:28:24 -0400 Prarit Bhargava <[email protected]> wrote:
Quoted 67 lines · Greg Kroah-Hartman
Quoted 63 lines · Prarit Bhargava
ACPI may contain an SPCR table that defines a default system console. On ARM if the table is present then the SPCR console is enabled by default. On x86 the SPCR console is used if 'earlycon' (no parameters) is specified as a kernel parameter and is used only as the early console. To use the SPCR data as a console a user must boot with 'earlycon', grep logs & specify a console= kernel parameter, and then reboot again.
Add 'console=auto' that enables a firmware or hardware console, and on x86 enable the SPCR console if 'console=auto' is specified.
Tested on systems with and without an ACPI SPCR. The following kernel parameters were also tested:
console=ttyS0,115200 works earlycon works (early console only) console=auto works (full console as expected)no console or earlycon arguments works (no output as expected)
Signed-off-by Prarit Bhargava <[email protected]>Cc Mark Salter <[email protected]>Cc Al Stone <[email protected]>Cc "Rafael J. Wysocki" <[email protected]>Cc Len Brown <[email protected]>Cc Pavel Machek <[email protected]>Cc Petr Mladek <[email protected]>Cc Sergey Senozhatsky <[email protected]>Cc Steven Rostedt <[email protected]>Cc Kees Cook <[email protected]>Cc Greg Kroah-Hartman <[email protected]>--- Documentation/admin-guide/kernel-parameters.txt | 1 + arch/x86/kernel/acpi/boot.c | 5 +++++ include/linux/console.h | 1 + kernel/printk/printk.c | 10 ++++++++++ 4 files changed, 17 insertions(+)Documentation/admin-guide/kernel-parameters.txt +1
-0@@ -635,6 +635,7 @@ hvc<n> Use the hypervisor console device <n>. This is for both Xen and PowerPC hypervisors. + auto [X86] Enable ACPI SPCR console If the device connected to the port is not a TTY but a braille device, prepend "brl," before the device type, for instancearch/x86/kernel/acpi/boot.c +5
-0@@ -1771,3 +1771,8 @@ void __init arch_reserve_mem_area(acpi_physical_address addr, size_t size)e820__range_add (addr, size,E820_TYPE_ACPI );e820__update_table_print (); } + +void __init arch_console_setup (void ) +{ +acpi_parse_spcr (false, true); +}<snip>
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
+int
arch_console_setup(void);Function does not match its prototype :(
How did you build this successfully?
Weird, it compiles on my system?
Are you compiling with ACPI enabled?
It would still compile without it and use the properly prototyped "weak" function.
-- Steve
Quoted 3 lines
I'll fix it though.
Quoted 73 lines · Steven Rostedt
Quoted 70 lines · On Thu, 16 Aug 2018 11:28:24 -0400 Prarit Bhargava <[email protected]> wrote:
Quoted 69 lines · Greg Kroah-Hartman
Quoted 63 lines · Prarit Bhargava
ACPI may contain an SPCR table that defines a default system console. On ARM if the table is present then the SPCR console is enabled by default. On x86 the SPCR console is used if 'earlycon' (no parameters) is specified as a kernel parameter and is used only as the early console. To use the SPCR data as a console a user must boot with 'earlycon', grep logs & specify a console= kernel parameter, and then reboot again.
Add 'console=auto' that enables a firmware or hardware console, and on x86 enable the SPCR console if 'console=auto' is specified.
Tested on systems with and without an ACPI SPCR. The following kernel parameters were also tested:
console=ttyS0,115200 works earlycon works (early console only) console=auto works (full console as expected)no console or earlycon arguments works (no output as expected)
Signed-off-by Prarit Bhargava <[email protected]>Cc Mark Salter <[email protected]>Cc Al Stone <[email protected]>Cc "Rafael J. Wysocki" <[email protected]>Cc Len Brown <[email protected]>Cc Pavel Machek <[email protected]>Cc Petr Mladek <[email protected]>Cc Sergey Senozhatsky <[email protected]>Cc Steven Rostedt <[email protected]>Cc Kees Cook <[email protected]>Cc Greg Kroah-Hartman <[email protected]>--- Documentation/admin-guide/kernel-parameters.txt | 1 + arch/x86/kernel/acpi/boot.c | 5 +++++ include/linux/console.h | 1 + kernel/printk/printk.c | 10 ++++++++++ 4 files changed, 17 insertions(+)Documentation/admin-guide/kernel-parameters.txt +1
-0@@ -635,6 +635,7 @@ hvc<n> Use the hypervisor console device <n>. This is for both Xen and PowerPC hypervisors. + auto [X86] Enable ACPI SPCR console If the device connected to the port is not a TTY but a braille device, prepend "brl," before the device type, for instancearch/x86/kernel/acpi/boot.c +5
-0@@ -1771,3 +1771,8 @@ void __init arch_reserve_mem_area(acpi_physical_address addr, size_t size)e820__range_add (addr, size,E820_TYPE_ACPI );e820__update_table_print (); } + +void __init arch_console_setup (void ) +{ +acpi_parse_spcr (false, true); +}<snip>
Quoted 1 line
+int
arch_console_setup(void);
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Function does not match its prototype :(
How did you build this successfully?
Weird, it compiles on my system?
Are you compiling with ACPI enabled?
Yes, CONFIG_ACPI is enabled.
Quoted 2 lines
It would still compile without it and use the properly prototyped "weak" function.
I did this:
1. git co linux.git 2. git am 0001-console-Add-console-auto-option.patch 3. make -j224
and I have a clean compile with no warnings or errors. My config is the standard Fedora .config so it has CONFIG_ACPI enabled and CONFIG_ACPI_SPCR_TABLE enabled.
IMO the compile should have warned or error'd out. Is there a possibility that some subtlety of weak functions that causes this to not be an error?
In any case, I've changed the prototype and other functions to void and am finishing up retesting.
P.
Quoted 6 lines
-- Steve
Quoted 3 lines
I'll fix it though.
PATCH v2 1/1 console: Add console=auto option
ACPI may contain an SPCR table that defines a default system console. On ARM if the table is present then the SPCR console is enabled by default. On x86 the SPCR console is used if 'earlycon' (no parameters) is specified as a kernel parameter and is used only as the early console. To use the SPCR data as a console a user must boot with 'earlycon', grep logs & specify a console= kernel parameter, and then reboot again.
Add 'console=auto' that enables a firmware or hardware console, and on x86 enable the SPCR console if 'console=auto' is specified.
Tested on systems with and without an ACPI SPCR. The following kernel parameters were also tested:
console=ttyS0,115200 works earlycon works (early console only) console=auto works (full console as expected)
no console or earlycon arguments works (no output as expected)
v2: Fix prototype.
--- Documentation/admin-guide/kernel-parameters.txt | 1 + arch/x86/kernel/acpi/boot.c | 5 +++++ include/linux/console.h | 1 + kernel/printk/printk.c | 10 ++++++++++ 4 files changed, 17 insertions(+)
Documentation/admin-guide/kernel-parameters.txt +1 -0
@@ -635,6 +635,7 @@ hvc<n> Use the hypervisor console device <n>. This is for both Xen and PowerPC hypervisors. + auto [X86] Enable ACPI SPCR console If the device connected to the port is not a TTY but a braille device, prepend "brl," before the device type, for instance
arch/x86/kernel/acpi/boot.c +5 -0
@@ -1771,3 +1771,8 @@ void __init arch_reserve_mem_area(acpi_physical_address addr, size_t size)e820__range_add (addr, size,E820_TYPE_ACPI );e820__update_table_print (); } + +void __init arch_console_setup (void ) +{ +acpi_parse_spcr (false, true); +}
include/linux/console.h +1 -0
@@ -181,6 +181,7 @@ extern int is_console_locked(void);extern int braille_register_console (struct console *,int index,char *console_options,char *braille_options);extern int braille_unregister_console (struct console *); +void arch_console_setup (void );#ifdef CONFIG_TTY extern void console_sysfs_notify (void );#else
kernel/printk/printk.c +10 -0
@@ -2078,6 +2078,11 @@ static int __init console_msg_format_setup(char *str) }__setup ("console_msg_format=" , console_msg_format_setup); +void __init __weak arch_console_setup (void ) +{ +return ; +} +/* * Set up a console. Called via do_early_param() in init/main.c * for each "console=" parameter in the boot command line.
@@ -2088,6 +2093,11 @@ static int __init console_setup(char *str)char *s, *options, *brl_options =NULL ;int idx; +if (!strcmp (str,"auto" )) { +arch_console_setup (); +return 1 ; + } +if (_braille_console_setup (&str, &brl_options))return 1 ;
Signature · 1 line
2.14.4
Petr Mladek
maintainerQuoted 9 lines · Prarit Bhargava
ACPI may contain an SPCR table that defines a default system console. On ARM if the table is present then the SPCR console is enabled by default. On x86 the SPCR console is used if 'earlycon' (no parameters) is specified as a kernel parameter and is used only as the early console. To use the SPCR data as a console a user must boot with 'earlycon', grep logs & specify a console= kernel parameter, and then reboot again.
Add 'console=auto' that enables a firmware or hardware console, and on x86 enable the SPCR console if 'console=auto' is specified.
I basically like the idea. Just one or two nits below.
Documentation/admin-guide/kernel-parameters.txt line 638
Quoted 9 lines
Documentation/admin-guide/kernel-parameters.txt +1
-0@@ -635,6 +635,7 @@ hvc<n> Use the hypervisor console device <n>. This is for both Xen and PowerPC hypervisors. + auto [X86] Enable ACPI SPCR console
The "auto" option sounds reasonable. But earlycon does exactly this when used without no extra options. I prefer to stay consistent with the existing earlycon behavior.
Quoted 7 lines
Documentation/admin-guide/kernel-parameters.txt +0
-0If the device connected to the port is not a TTY but a braille device, prepend "brl," before the device type, for instancearch/x86/kernel/acpi/boot.c +0
-0
arch/x86/kernel/acpi/boot.c void __init arch_reserve_mem_area(acpi_physical_address addr, size_t size) · line 1777
Quoted 7 lines
arch/x86/kernel/acpi/boot.c +4
-0@@ -1771,3 +1771,8 @@ void __init arch_reserve_mem_area(acpi_physical_address addr, size_t size)e820__range_add (addr, size,E820_TYPE_ACPI );e820__update_table_print (); } + +void __init arch_console_setup (void ) +{ +acpi_parse_spcr (false, true);
Just for record. I was curious that this might be called twice (also from acpi_boot_init(). But it looks safe after all.
The trick is in the two bool parameters. One call allows to register/enable earlycon and ignores normal console. This other call does exactly the opposite. I do not see any unwanted side effects.
Best Regards,
Petr
Quoted 20 lines · Petr Mladek
Quoted 9 lines · Prarit Bhargava
ACPI may contain an SPCR table that defines a default system console. On ARM if the table is present then the SPCR console is enabled by default. On x86 the SPCR console is used if 'earlycon' (no parameters) is specified as a kernel parameter and is used only as the early console. To use the SPCR data as a console a user must boot with 'earlycon', grep logs & specify a console= kernel parameter, and then reboot again.
Add 'console=auto' that enables a firmware or hardware console, and on x86 enable the SPCR console if 'console=auto' is specified.
I basically like the idea. Just one or two nits below.
Quoted 6 lines
Documentation/admin-guide/kernel-parameters.txt +0
-0@@ -635,6 +635,7 @@
Quoted 7 lines
Documentation/admin-guide/kernel-parameters.txt line 638
Quoted 3 lines
Documentation/admin-guide/kernel-parameters.txt +1
-0hvc<n> Use the hypervisor console device <n>. This is for both Xen and PowerPC hypervisors. + auto [X86] Enable ACPI SPCR consoleThe "auto" option sounds reasonable. But earlycon does exactly this when used without no extra options. I prefer to stay consistent with the existing earlycon behavior.
Hi Petr, on x86 earlycon still only enables the early console but does not enable the console.
Quoted 11 lines
Quoted 11 lines
Documentation/admin-guide/kernel-parameters.txt +0
-0If the device connected to the port is not a TTY but a braille device, prepend "brl," before the device type, for instancearch/x86/kernel/acpi/boot.c +0
-0@@ -1771,3 +1771,8 @@ void __init arch_reserve_mem_area(acpi_physical_address addr, size_t size)e820__range_add (addr, size,E820_TYPE_ACPI );e820__update_table_print ();
Quoted 9 lines
arch/x86/kernel/acpi/boot.c void __init arch_reserve_mem_area(acpi_physical_address addr, size_t size) · line 1777
Quoted 5 lines
arch/x86/kernel/acpi/boot.c +4
-0} + +void __init arch_console_setup (void ) +{ +acpi_parse_spcr (false, true);Just for record. I was curious that this might be called twice (also from
acpi_boot_init(). But it looks safe after all.
Yes, the console code prevents the same console from being registered twice.
Quoted 4 lines
The trick is in the two bool parameters. One call allows to register/enable earlycon and ignores normal console. This other call does exactly the opposite. I do not see any unwanted side effects.
Thanks. I'd like to know if you (or anyone else) has strong feelings about changing the behaviour of earlycon on x86? I could make it so that specifying just earlycon would also initialize the console.
P.
Quoted 4 lines
Best Regards,
Petr
Documentation/admin-guide/kernel-parameters.txt line 638
Quoted 2 lines · Prarit Bhargava
Documentation/admin-guide/kernel-parameters.txt +1
-0+ auto [X86] Enable ACPI SPCR console
^^^^ And arm64?
Any chance we can rename param to "spcr" or something more clear? To explicitly state what exactly it's going to do. `auto' sounds too general and doesn't tell me that much. I'm probably the only here who can't see a connection between "auto" and "SPCR", but still.
One more thing, as far as I can tell, acpi_parse_spcr() can fail and return an error. arch_console_setup() hides all errors and returns void. Should it return error code?
int arch_console_setup(void)
{
return acpi_parse_spcr(false, true);
}Or maybe
void arch_console_setup(void)
{
if (acpi_parse_spcr(false, true))
pr_err(.........);
}There can be other consoles in the system, logging an error is not such a useless thing.
-ss
Quoted 5 lines · Sergey Senozhatsky
Documentation/admin-guide/kernel-parameters.txt line 638
Quoted 2 lines · Prarit Bhargava
Documentation/admin-guide/kernel-parameters.txt +1
-0+ auto [X86] Enable ACPI SPCR console^^^^ And arm64?
Hi Sergey, on arm64 if an SPCR is present the early console and console are initialized by default. IOW no kernel parameter is necessary to initialize the console in that case.
Quoted 7 lines
Any chance we can rename param to "spcr" or something more clear? To explicitly state what exactly it's going to do. `auto' sounds too general and doesn't tell me that much. I'm probably the only here who can't see a connection between "auto" and "SPCR", but still.
I came up with "auto" because I think it is generic. I also thought about "console=fw", or just "console". If in the future another arch wants to optionally bring up a firmware or hardware defined console then they could use auto too.
Quoted 12 lines
One more thing, as far as I can tell,
acpi_parse_spcr()can fail and return an error.arch_console_setup()hides all errors and returns void. Should it return error code?int arch_console_setup(void) { return acpi_parse_spcr(false, true); }Or maybe
Quoted 8 lines
void arch_console_setup(void) { if (acpi_parse_spcr(false, true)) pr_err(.........); }There can be other consoles in the system, logging an error is not such a useless thing.
I can make the second change. The problem (IIRC) with returning an error in an setup fn is that the rest of the setup functions will not execute. I don't want to fail the setup callbacks because of an incorrect SPCR table.
Like I mentioned to Petr, I'd like to know if you (or anyone else) has strong feelings about changing the behaviour of earlycon on x86? I could make it so that specifying just earlycon would also initialize the console.
P.
Quoted 3 lines
-ss
Hello,
Cc-ing Peter Zijlstra
lkml.kernel.org/r/[email protected] lkml.kernel.org/r/[email protected] lkml.kernel.org/r/[email protected]
Quoted 10 lines · Prarit Bhargava
Quoted 5 lines · Sergey Senozhatsky
Documentation/admin-guide/kernel-parameters.txt line 638
Quoted 2 lines · Prarit Bhargava
Documentation/admin-guide/kernel-parameters.txt +1
-0+ auto [X86] Enable ACPI SPCR console^^^^ And arm64?Hi Sergey, on arm64 if an SPCR is present the early console and console are initialized by default. IOW no kernel parameter is necessary to initialize the console in that case.
OK, thanks.
Quoted 10 lines
Quoted 5 lines
Any chance we can rename param to "spcr" or something more clear? To explicitly state what exactly it's going to do. `auto' sounds too general and doesn't tell me that much. I'm probably the only here who can't see a connection between "auto" and "SPCR", but still.
I came up with "auto" because I think it is generic. I also thought about "console=fw", or just "console". If in the future another arch wants to optionally bring up a firmware or hardware defined console then they could use auto too.
Hmm, I see your point.
My [sort of a] problem with "auto" is that it tells me as much as "magic" [and "magic" tells me almost nothing]. By the way, would be fun if we had "magic" instead of "auto" all over the kernel
echo "magic" > /sys/bus/usb/...../power/control
Quoted 6 lines
Quoted 6 lines
void arch_console_setup(void) { if (acpi_parse_spcr(false, true)) pr_err(.........); }
Quoted 6 lines
Quoted 2 lines
There can be other consoles in the system, logging an error is not such a useless thing.
I can make the second change. The problem (IIRC) with returning an error in an setup fn is that the rest of the setup functions will not execute. I don't want to fail the setup callbacks because of an incorrect SPCR table.
OK, fair enough.
Letting users know that SPCR is incorrect also makes sense, so option #2 I guess is what we want after all.
Quoted 3 lines
Like I mentioned to Petr, I'd like to know if you (or anyone else) has strong feelings about changing the behaviour of earlycon on x86? I could make it so that specifying just earlycon would also initialize the console.
x86 people and/or scheduler people might have strong opinions on this. I Cc-ed Peter Zijlstra; he represents both groups and is known to be a hardcore earlycon user.
-ss
Quoted 57 lines · Sergey Senozhatsky
Hello,
Cc-ing Peter Zijlstra
lkml.kernel.org/r/[email protected] lkml.kernel.org/r/[email protected] lkml.kernel.org/r/[email protected]
Quoted 10 lines · Prarit Bhargava
Quoted 5 lines · Sergey Senozhatsky
Documentation/admin-guide/kernel-parameters.txt line 638
Quoted 2 lines · Prarit Bhargava
Documentation/admin-guide/kernel-parameters.txt +1
-0+ auto [X86] Enable ACPI SPCR console^^^^ And arm64?Hi Sergey, on arm64 if an SPCR is present the early console and console are initialized by default. IOW no kernel parameter is necessary to initialize the console in that case.
OK, thanks.
Quoted 10 lines
Quoted 5 lines
Any chance we can rename param to "spcr" or something more clear? To explicitly state what exactly it's going to do. `auto' sounds too general and doesn't tell me that much. I'm probably the only here who can't see a connection between "auto" and "SPCR", but still.
I came up with "auto" because I think it is generic. I also thought about "console=fw", or just "console". If in the future another arch wants to optionally bring up a firmware or hardware defined console then they could use auto too.
Hmm, I see your point.
My [sort of a] problem with "auto" is that it tells me as much as "magic" [and "magic" tells me almost nothing]. By the way, would be fun if we had "magic" instead of "auto" all over the kernelecho "magic" > /sys/bus/usb/...../power/controlQuoted 6 lines
Quoted 6 lines
void arch_console_setup(void) { if (acpi_parse_spcr(false, true)) pr_err(.........); }Quoted 6 lines
Quoted 2 lines
There can be other consoles in the system, logging an error is not such a useless thing.
I can make the second change. The problem (IIRC) with returning an error in an setup fn is that the rest of the setup functions will not execute. I don't want to fail the setup callbacks because of an incorrect SPCR table.
OK, fair enough.
Letting users know that SPCR is incorrect also makes sense, so option #2 I guess is what we want after all.
Quoted 7 lines
Quoted 3 lines
Like I mentioned to Petr, I'd like to know if you (or anyone else) has strong feelings about changing the behaviour of earlycon on x86? I could make it so that specifying just earlycon would also initialize the console.
x86 people and/or scheduler people might have strong opinions on this. I Cc-ed Peter Zijlstra; he represents both groups and is known to be a hardcore earlycon user.
Thanks, I'm a user of earlycon too, but only moderately.
peterz, to give you an overview: Currently on x86, the SPCR information is only interpreted by the early console code, and can be enabled with kernel parameter "earlycon" (no arguments). In this patch I'm proposing adding "console=auto" that would enable the console based on the SPCR data.
There are two options on the table. One, we could go with this patch which would make users do "earlycon console=auto" or, I could just change the behaviour of earlycon (no arguments) to also bring up the console. In the second case the kernel parameter would just be "earlycon". There is precedent for the second option as arm64 enables both the earlycon and console by default if SPCR is present. However, on x86, I know many users do not want the console enabled by default so we should keep it on demand.
tl;dr: Pick one
Option 1: earlycon enables both the early console and console. Option 2: earlycon only enables the early console, and console=auto enables the console.
P.
Quoted 3 lines
-ss
Petr Mladek
maintainerQuoted 24 lines · Prarit Bhargava
Quoted 7 lines · Sergey Senozhatsky
Quoted 3 lines
Like I mentioned to Petr, I'd like to know if you (or anyone else) has strong feelings about changing the behaviour of earlycon on x86? I could make it so that specifying just earlycon would also initialize the console.
x86 people and/or scheduler people might have strong opinions on this. I Cc-ed Peter Zijlstra; he represents both groups and is known to be a hardcore earlycon user.
Thanks, I'm a user of earlycon too, but only moderately.
peterz, to give you an overview: Currently on x86, the SPCR information is only interpreted by the early console code, and can be enabled with kernel parameter "earlycon" (no arguments). In this patch I'm proposing adding "console=auto" that would enable the console based on the SPCR data.
There are two options on the table. One, we could go with this patch which would make users do "earlycon console=auto" or, I could just change the behaviour of earlycon (no arguments) to also bring up the console. In the second case the kernel parameter would just be "earlycon". There is precedent for the second option as arm64 enables both the earlycon and console by default if SPCR is present. However, on x86, I know many users do not want the console enabled by default so we should keep it on demand.
Quoted 3 lines
tl;dr: Pick one
Option 1: earlycon enables both the early console and console.
I am afraid that this is not acceptable. Users are sensitive when a new kernel suddenly enables different consoles. For example, see:
+ commit dac8bbbae1d0ccba9 ("Revert "printk: fix double printing with earlycon")
+ commit c6c7d83b9c9e6a8b3 ("Revert "console: don't prefer first registered if DT specifies stdout-path")
By other words, the new behavior must depend on a new option.
Quoted 2 lines
Option 2: earlycon only enables the early console, and console=auto enables the console.
I suggest:
Option 3: "earlycon" enables early console defined by SPCR
"console" enables console defined by SPCR
I mean that "console" without extra options would enable the console defined by ACPI SPCR. It would work the same as "earlycon" without extra options for early consoles.
If you would want to make it explicit than I agree with Sergey and would prefer "console=spcr" instead of "console=auto".
Note kernel tries to enable some consoles automatically even when "console" parameter is not defined at all. Therefore "auto" is somehow misleading.
Best Regards,
Petr
PS: JFYI, I have vacation the following week...
Quoted 51 lines · Petr Mladek
Quoted 24 lines · Prarit Bhargava
Quoted 7 lines · Sergey Senozhatsky
Quoted 3 lines
Like I mentioned to Petr, I'd like to know if you (or anyone else) has strong feelings about changing the behaviour of earlycon on x86? I could make it so that specifying just earlycon would also initialize the console.
x86 people and/or scheduler people might have strong opinions on this. I Cc-ed Peter Zijlstra; he represents both groups and is known to be a hardcore earlycon user.
Thanks, I'm a user of earlycon too, but only moderately.
peterz, to give you an overview: Currently on x86, the SPCR information is only interpreted by the early console code, and can be enabled with kernel parameter "earlycon" (no arguments). In this patch I'm proposing adding "console=auto" that would enable the console based on the SPCR data.
There are two options on the table. One, we could go with this patch which would make users do "earlycon console=auto" or, I could just change the behaviour of earlycon (no arguments) to also bring up the console. In the second case the kernel parameter would just be "earlycon". There is precedent for the second option as arm64 enables both the earlycon and console by default if SPCR is present. However, on x86, I know many users do not want the console enabled by default so we should keep it on demand.
Quoted 3 lines
tl;dr: Pick one
Option 1: earlycon enables both the early console and console.
I am afraid that this is not acceptable. Users are sensitive when a new kernel suddenly enables different consoles. For example, see:
+ commit
dac8bbbae1d0ccba9("Revert "printk: fix double printing with earlycon")+ commit
c6c7d83b9c9e6a8b3("Revert "console: don't prefer first registered if DT specifies stdout-path")By other words, the new behavior must depend on a new option.
Quoted 2 lines
Option 2: earlycon only enables the early console, and console=auto enables the console.
I suggest:
Option 3: "earlycon" enables early console defined by SPCR
"console" enables console defined by SPCR
Quoted 6 lines
I mean that "console" without extra options would enable the console defined by ACPI SPCR. It would work the same as "earlycon" without extra options for early consoles.
If you would want to make it explicit than I agree with Sergey and would prefer "console=spcr" instead of "console=auto".
I'm going with "console=spcr". FYI.
P.
Quoted 10 lines
Note kernel tries to enable some consoles automatically even when "console" parameter is not defined at all. Therefore "auto" is somehow misleading.
Best Regards,
PetrPS: JFYI, I have vacation the following week...