Re: [PATCH v2] init: Don't proxy `console=` to earlycon

[Raul Rangel]

On Tue, Oct 1, 2024 at 9:09 AM Petr Mladek <pmladek@xxxxxxxx> wrote:
>
> On Tue 2024-09-24 10:05:08, Raul Rangel wrote:
> > On Thu, Sep 19, 2024 at 6:57 AM Petr Mladek <pmladek@xxxxxxxx> wrote:
> >
> > > On Wed 2024-09-11 12:35:14, Raul E Rangel wrote:
> > > > Today we are proxying the `console=` command line args to the
> > > > `param_setup_earlycon()` handler. This is done because the following are
> > > > equivalent:
> > > >
> > > >     console=uart[8250],mmio,<addr>[,options]
> > > >     earlycon=uart[8250],mmio,<addr>[,options]
> > > >
> > > > Both invocations enable an early `bootconsole`. `console=uartXXXX` is
> > > > just an alias for `earlycon=uartXXXX`.
> > > >
> > > > In addition, when `earlycon=` (empty value) or just `earlycon`
> > > > (no value) is specified on the command line, we enable the earlycon
> > > > `bootconsole` specified by the SPCR table or the DT.
> > > >
> > > > The problem arises when `console=` (empty value) is specified on the
> > > > command line. It's intention is to disable the `console`, but what
> > > > happens instead is that the SPRC/DT console gets enabled.
> > > >
> > > > This happens because we are proxying the `console=` (empty value)
> > > > parameter to the `earlycon` handler. The `earlycon` handler then sees
> > > > that the parameter value is empty, so it enables the SPCR/DT
> > > > `bootconsole`.
> > > >
> > > > This change makes it so that the `console` or `console=` parameters no
> > > > longer enable the SPCR/DT `bootconsole`. I also cleans up the hack in
> > > > `main.c` that would forward the `console` parameter to the `earlycon`
> > > > handler.
> > > >
> > > > Signed-off-by: Raul E Rangel <rrangel@xxxxxxxxxxxx>
> > >
> > > It like this approach. It works well:
> > >
> > > Reviewed-by: Petr Mladek <pmladek@xxxxxxxx>
> > > Tested-by: Petr Mladek <pmladek@xxxxxxxx>
> > >
> >
> > Thanks for reviewing and testing! I know it takes a significant amount of
> > time, so thank you.
> >
> > >
> > > I could take it via the printk tree for 6.13. From my POV, it is too
> > > late for 6.12. I am sorry I have been busy with the printk rework :-(
> > >
> >
> > 6.13 is fine. As long as it lands upstream I can cherry pick the patch into
> > our forks without any pushback.
>
> JFYI, the patch has been committed into printk/linux.git,
> branch for-6.13.

Thank you!
>
> Best Regards,
> Petr