From: Doug Anderson <email@example.com>
To: Daniel Thompson <firstname.lastname@example.org>
Cc: Jason Wessel <email@example.com>,
Sumit Garg <firstname.lastname@example.org>,
email@example.com, LKML <firstname.lastname@example.org>,
Patch Tracking <email@example.com>
Subject: Re: [PATCH v2] serial: kgdboc: Allow earlycon initialization to be deferred
Date: Thu, 21 May 2020 10:18:10 -0700 [thread overview]
Message-ID: <CAD=FV=Xut=5y-MyJSu+ERdMRkKbSf8SGMhUHg5OP=y8zA1N-xQ@mail.gmail.com> (raw)
On Thu, Apr 30, 2020 at 9:47 AM Doug Anderson <firstname.lastname@example.org> wrote:
> On Thu, Apr 30, 2020 at 9:18 AM Daniel Thompson
> <email@example.com> 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 <firstname.lastname@example.org>
> > ---
> > 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 <email@example.com>
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
next prev parent reply other threads:[~2020-05-21 17:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 17:08 [PATCH] serial: kgdboc: Allow earlycon initialization to be deferred Daniel Thompson
2020-04-30 0:32 ` Doug Anderson
2020-04-30 10:23 ` Daniel Thompson
2020-04-30 16:17 ` [PATCH v2] " Daniel Thompson
2020-04-30 16:47 ` Doug Anderson
2020-05-21 17:18 ` Doug Anderson [this message]
2020-05-22 15:30 ` Daniel Thompson
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.