On Wed, Oct 22, 2014 at 9:47 PM, Rob Herring [off-list ref] wrote:

quoted

Now that earlycon can get all of its parameters from DT, do you think
it might make sense to drop the command line option entirely from
fdt.c and enable it all of the time if stdout-path is set correctly?

From the user's standpoint, how important is it to be able to run
without earlycon?

It may affect boot time for one although if you care you probably
disable console altogether.

I think we'd just have to add a noearlycon option instead if we made
it the default. It's never been the default before, so I don't think
we should change now. There's also an implicit requirement that the
bootloader has configured the uart already. You could easily hang if
the uart has not been setup.

EARLY_PRINTK is enabled by default on MIPS platforms that support it.
I have been using this for years and found it very helpful in
debugging failures in the kernel boot process (especially intermittent
ones).

But for a new platform it is better to use earlycon as earlycon
provides a clean way of reading the UART information out of DT.  My
original bcm3384 (MIPS) port used EARLY_PRINTK but I recently
converted it to earlycon.  The last remaining goal is to get it
enabled by default again.

quoted

Would it be more straightforward to have the arch code explicitly call
early_init_dt_scan_chosen_serial() to indicate that it is ready for
the early UART driver to run?

Yes, but then when do you handle earlycon command line option for
non-DT case? Having these at different points in time is asking for
problems.

Is it important for the non-DT "earlycon" option to be handled from
parse_early_param() just because parse_early_param() runs at the right
point in the boot sequence (not because we actually wanted it to be a
command line option)?

One other option might be to invoke early_init_dt_scan_chosen_serial()
from parse_early_param().  But it is somewhat clunky to put a special
case in there...