Re: [PATCH v5 09/16] printk: Allow to override options via the command line

[Chris Down]

Petr Mladek writes:
>Consoles can be preferred either via the console= command line parameter
>or by some platform specific code, e.g. SPCR, device tree.

On v4 I recall you said you would probably do the change in a separate series. 
I think that is still the better plan: the rest of the series is a clean-up and 
it would be nice to keep it that way.

>-	 * Historically, the preferred options are stored only by the first
>-	 * caller who prefers the particular console.
>+	 * Allow to override options via the command line but always
>+	 * prefer the Braille variant.
> 	 */
>-	if (is_new_entry) {
>+	if (is_new_entry || brl_options ||
>+	    (user_specified && !is_braille_console_preferred(pc))) {

This also clears options when the later console= has none, which v4 did not do. 
That breaks at least the MIPS boards that pass the firmware baud rate from 
setup_arch():

    arch/mips/sgi-ip22/ip22-setup.c: add_preferred_console("ttyS", n, dbaud)
    arch/mips/sgi-ip32/ip32-setup.c: add_preferred_console("ttyS", n, dbaud)
    arch/mips/sni/setup.c:           add_preferred_console("ttyS"/"ttySC", port, baud)

With "console=ttyS0" and no options, the drivers there (ip22zilog, 8250, 
sccnxp) fall back to 9600, and anyone with the firmware set to another rate is 
gonna have a bad time.

It also makes a bare "console=uart" after an SPCR "uart" entry oops because 
univ8250_console_match() hands the now-NULL options to uart_parse_earlycon().

(A bare console=uart on its own already oopses in the base, so that part is an 
older 8250 problem, but this patch adds a fun new way to get there.)

If you want to keep it here, could it at least only override when the command 
line actually provides options?