Re: [PATCH v3] console: use first console if stdout-path device doesn't appear

[Sergey Senozhatsky <sergey.senozhatsky@gmail.com>]

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?

[..]
> @@ -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?

> +			 */
> +			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
>