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

[Petr Mladek]

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.

Best Regards,
Petr