Re: [PATCH v3] console: use first console if stdout-path device doesn't appear
From: Sergey Senozhatsky <hidden>
Date: 2016-11-03 17:41:50
Also in:
lkml
Possibly related (same subject, not in this thread)
- 2016-11-04 · Re: [PATCH v3] console: use first console if stdout-path device doesn't appear · Andreas Schwab <hidden>
On (11/03/16 12:57), Paul Burton wrote:
If a device tree specified a preferred device for kernel console output via the stdout-path or linux,stdout-path chosen node properties there's no guarantee that it will have specified a device for which we have a driver. It may also be the case that we do have a driver but it doesn't call of_console_check() to register as a preferred console (eg. offb driver as used on powermac systems).
so why that driver doesn't call of_console_check() then? if there is a misconfiguration then why do we want to fix it/fallback in printk code? [..]
quoted hunk ↗ jump to hunk
@@ -260,10 +260,18 @@ void console_set_by_of(void) { of_specified_console = true; } + +static void clear_of_specified_console(void) +{ + of_specified_console = false; +} #else # define of_specified_console false +static void clear_of_specified_console(void) { } #endif +struct console *of_fallback_console; + /* Flag: console code may call schedule() */ static int console_may_schedule;@@ -2657,10 +2665,26 @@ void register_console(struct console *newcon) * didn't select a console we take the first one * that registers here. */ - if (preferred_console < 0 && !of_specified_console) { + if (preferred_console < 0) { if (newcon->index < 0) newcon->index = 0; - if (newcon->setup == NULL || + if (of_specified_console) { + /* + * The device tree stdout-path chosen node property was + * specified so we don't want to enable the first + * registered console just now in order to give the + * device indicated by stdout-path a chance to be + * registered first. Do however keep track of the + * first console we see so that we can fall back to + * using it if we don't see the desired device, either + * because stdout-path isn't valid, or because we have + * no driver for the device or our driver doesn't call + * of_console_check(). See printk_late_init() for this + * fallback.
if the path is not valid then correct the path. no?
quoted hunk ↗ jump to hunk
+ */ + if (!of_fallback_console) + of_fallback_console = newcon; + } else if (newcon->setup == NULL || newcon->setup(newcon, NULL) == 0) { newcon->flags |= CON_ENABLED; if (newcon->device) {@@ -2844,6 +2868,22 @@ static int __init printk_late_init(void) { struct console *con; + if (of_specified_console && of_fallback_console && + (!console_drivers || !(console_drivers->flags & CON_CONSDEV))) { + /* + * The system has a device tree which specified stdout-path, + * but we haven't seen a console associated with the device + * specified by the stdout-path chosen node property. + * + * We do however know which console would have been used + * if stdout-path weren't specified at all, so in an attempt + * to provide some output we'll re-register that console + * pretending that we never saw stdout-path. + */
DT screwed up, so why would printk() care? does any other sub-system/driver fixes up a DT misconfiguration? -ss
+ clear_of_specified_console();
+ register_console(of_fallback_console);
+ }
+
for_each_console(con) {
if (!keep_bootcon && con->flags & CON_BOOT) {
/*
--
2.10.2