* Tony Lindgren <tony@xxxxxxxxxxx> [231208 10:29]: > * Tony Lindgren <tony@xxxxxxxxxxx> [700101 02:00]: > > * Tony Lindgren <tony@xxxxxxxxxxx> [700101 02:00]: > > > We also prepare the serial core to handle the ttyS related quirks done > > > in console_setup() to prepare things for eventually dropping the parsing > > > from console_setup(). This can only happen after further changes to > > > register_console(). > > > > Petr FYI, so for dropping the console_setup() parsing, below is a hack > > patch to see what goes wrong in register_console() if you have some ideas > > on how to handle this. > > > > We end up with the console device backed up seria8250 instead of ttyS0, > > and earlycon won't get properly disabled. And of course other consoles > > beyond ttyS need to be also considered. > > Hmm so the following extra patch seems to fix the issues based on light > testing. But is it safe to assume that if CON_PRINTBUFFER is set we can > disable the bootconsole? OK so no need for the CON_PRINTBUFFER change, it's wrong. I found a few bugs causing this issue and a lot of other confusion while testing: - In console_setup(), a DEVNAME:0.0 style console can get added with the IO address turned into a ttyS console with some crazy index :) So we need to bail out early on consoles with ':' in the name. - The brl_opts can be empty or NULL, but we need to pass NULL to __add_preferred_console() to get CON_CONSDEV flag set for DEVNAME:0.0 console. Otherwise the preferred_console won't get set and the boot console won't get disabled. - The console_set_on_cmdline flag needs to be set if console_setup() does not call __add_preferred_console() for DEVNAME:0.0 style console as otherwise try_enable_default_console() may get called before the console handling driver has added the preferred console. I think with these the remaining issues are sorted out :) I'll post a v5 set with as RFC as it's getting close to the merge window. Regards, Tony
