On Tue 2020-10-06 15:43:28, Petr Mladek wrote: > On Tue 2020-10-06 03:45:00, Guenter Roeck wrote: > > On 10/6/20 2:52 AM, Petr Mladek wrote: > > > And it makes perfect sense to disable all consoles or drop all defined > > > by dts. But I would prefer to make it more obvious way, for > > > example by parameters like: > > > > > > + console=none > > > + no-console > > > + no-dtd-console > > > + no-default-console > > > > > Again, the problem isn't limited to dts provided consoles, or at least > > that was my understanding. I am still trying to understand how default > > consoles are defined, so I may get something wrong. Anyway, personally I > > liked "console=", but that is just me. Anything else should work for us > > as long as it is backward compatible (which excludes the no-xxx options). > > Here is my understanding: > > The consoles can be defined by scpr, dts, and on the command line. It > is anyone calling add_preferred_console(). > > Then the various devices call register_console(). They are registered > only when they match any console in console_cmdline[] array, see > try_enable_new_console(). > > > Whatever is decided, I'd like to have it made official and documented to > > avoid a similar problem in the future.
Sigh, it is even bigger mess than I expected. There is a magic variable "console_set_on_cmdline". It used, for example, in of_console_check() to prevent using the default console from dts. It is used on few more locations to prevent the default console. But there are other locations when add_preferred_console() is called without checking this variable. As a result, "console=" has different effect on different systems. I tend to revert the problematic patch now. And I would try to clean up this mess for-5.11. There is a big chance that people used the empty console= only on systems where it disabled all default consoles. I would try to make it the official global behavior. But this would need some longer testing in linux-next, ... Best Regards, Petr