Hi,

On Thu, Apr 30, 2020 at 9:47 AM Doug Anderson [off-list ref] wrote:

Hi,

On Thu, Apr 30, 2020 at 9:18 AM Daniel Thompson
[off-list ref] wrote:

quoted

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 <redacted>
---

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@chromium.org>

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!

-Doug