On Wed, Oct 22, 2014 at 9:47 PM, Rob Herring <robh@xxxxxxxxxx> wrote: >> 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. >> 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... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
