Re: [PATCH v2] serial: kgdboc: Allow earlycon initialization to be deferred

[Daniel Thompson]

On Thu, May 21, 2020 at 10:18:10AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Thu, Apr 30, 2020 at 9:47 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> >
> > Hi,
> >
> > On Thu, Apr 30, 2020 at 9:18 AM Daniel Thompson
> > <daniel.thompson@xxxxxxxxxx> wrote:
> > >
> > > Currently there is no guarantee that an earlycon will be initialized
> > > before kgdboc tries to adopt it. Almost the opposite: on systems
> > > with ACPI then if earlycon has no arguments then it is guaranteed that
> > > earlycon will not be initialized.
> > >
> > > This patch mitigates the problem by giving kgdboc_earlycon a second
> > > chance during console_init(). This isn't quite as good as stopping during
> > > early parameter parsing but it is still early in the kernel boot.
> > >
> > > Signed-off-by: Daniel Thompson <daniel.thompson@xxxxxxxxxx>
> > > ---
> > >
> > > Notes:
> > >     v2: Simplified, more robust, runs earlier, still has Doug's
> > >         recent patchset as a prerequisite. What's not to like?
> > >
> > >     More specifically, based on feedback from Doug Anderson, I
> > >     have replaced the initial hacky implementation with a console
> > >     initcall.
> > >
> > >     I also made it defer more aggressively after realizing that both
> > >     earlycon and kgdboc_earlycon are handled as early parameters
> > >     (meaning I think the current approach relies on the ordering
> > >     of drivers/tty/serial/Makefile to ensure the earlycon is enabled
> > >     before kgdboc tries to adopt it).
> > >
> > >     Finally, my apologies to Jason and kgdb ML folks, who are seeing
> > >     this patch for the first time. I copied the original circulation
> > >     list from a patch that wasn't kgdb related and forgot to update.
> > >
> > >  drivers/tty/serial/kgdboc.c | 41 +++++++++++++++++++++++++++++++++++--
> > >  1 file changed, 39 insertions(+), 2 deletions(-)
> >
> > Thanks, this looks great!
> >
> > Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
> 
> Are you planning to rebase this patch atop what landed?  It seems like
> a useful feature.  If you want me to give a shot a rebasing, let me
> know!

I've got it on it's way...


Daniel.