Thread (21 messages) 21 messages, 5 authors, 2016-11-08

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)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help