Message ID | 20200507200850.60646-1-dianders@chromium.org (mailing list archive) |
---|---|
Headers | show |
Series | kgdb: Support late serial drivers; enable early debug w/ boot consoles | expand |
On Thu, May 07, 2020 at 01:08:38PM -0700, Douglas Anderson wrote: > <snip> > > My first attempt was to try to get the existing "ekgdboc" to work > earlier. I tried that for a bit until I realized that it needed to > work at the tty layer and I couldn't find any serial drivers that > managed to register themselves to the tty layer super early at boot. > The only documented use of "ekgdboc" is "ekgdboc=kbd" and that's a bit > of a special snowflake. Trying to get my serial driver and all its > dependencies to probe normally and register the tty driver super early > at boot seemed like a bad way to go. In fact, all the complexity > needed to do something like this is why the system already has a > special concept of a "boot console" that lives only long enough to > transition to the normal console. > > <snip> > > The devices I had for testing were: > - arm32: rk3288-veyron-jerry > - arm64: rk3399-gru-kevin > - arm64: qcom-sc7180-trogdor (not mainline yet) > > These are the devices I tested this series on. I tried to test > various combinations of enabling/disabling various options and I > hopefully caught the corner cases, but I'd appreciate any extra > testing people can do. Notably I didn't test on x86, but (I think) I > didn't touch much there so I shouldn't have broken anything. I have tested a slightly earlier version using qemu and will test this set before it moves forwards. > .../admin-guide/kernel-parameters.txt | 20 ++ > Documentation/dev-tools/kgdb.rst | 24 ++ > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/debug-monitors.h | 2 + > arch/arm64/kernel/debug-monitors.c | 2 +- > arch/arm64/kernel/traps.c | 3 + > arch/x86/Kconfig | 1 + > drivers/tty/serial/8250/8250_early.c | 23 ++ > drivers/tty/serial/amba-pl011.c | 32 +++ > drivers/tty/serial/kgdboc.c | 268 ++++++++++++++++-- > drivers/tty/serial/qcom_geni_serial.c | 32 +++ > include/linux/kgdb.h | 4 + > kernel/debug/debug_core.c | 52 +++- > lib/Kconfig.kgdb | 18 ++ > 14 files changed, 436 insertions(+), 46 deletions(-) Any thoughts on how best to land these changes? AFAICT the arm64 and 8250/amba-pl011/qcom_geni_serial code could be applied independently of the kgdb changes (though we must keep changes to drivers/tty/serial/kgdboc alongside the kgdb changes). I can hoover them up but I'd need a solid set of acks and I don't think we've got that yet. I'd also be happy to ack where needed and let someone else pick it up (the other changes queued for kgdb this cycle are pretty small so we shouldn't see much conflict in kernel/debug/ ). Daniel.
Hi, On Thu, May 14, 2020 at 9:21 AM Daniel Thompson <daniel.thompson@linaro.org> wrote: > > On Thu, May 07, 2020 at 01:08:38PM -0700, Douglas Anderson wrote: > > <snip> > > > > My first attempt was to try to get the existing "ekgdboc" to work > > earlier. I tried that for a bit until I realized that it needed to > > work at the tty layer and I couldn't find any serial drivers that > > managed to register themselves to the tty layer super early at boot. > > The only documented use of "ekgdboc" is "ekgdboc=kbd" and that's a bit > > of a special snowflake. Trying to get my serial driver and all its > > dependencies to probe normally and register the tty driver super early > > at boot seemed like a bad way to go. In fact, all the complexity > > needed to do something like this is why the system already has a > > special concept of a "boot console" that lives only long enough to > > transition to the normal console. > > > > <snip> > > > > The devices I had for testing were: > > - arm32: rk3288-veyron-jerry > > - arm64: rk3399-gru-kevin > > - arm64: qcom-sc7180-trogdor (not mainline yet) > > > > These are the devices I tested this series on. I tried to test > > various combinations of enabling/disabling various options and I > > hopefully caught the corner cases, but I'd appreciate any extra > > testing people can do. Notably I didn't test on x86, but (I think) I > > didn't touch much there so I shouldn't have broken anything. > > I have tested a slightly earlier version using qemu and will test this > set before it moves forwards. > > > > .../admin-guide/kernel-parameters.txt | 20 ++ > > Documentation/dev-tools/kgdb.rst | 24 ++ > > arch/arm64/Kconfig | 1 + > > arch/arm64/include/asm/debug-monitors.h | 2 + > > arch/arm64/kernel/debug-monitors.c | 2 +- > > arch/arm64/kernel/traps.c | 3 + > > arch/x86/Kconfig | 1 + > > drivers/tty/serial/8250/8250_early.c | 23 ++ > > drivers/tty/serial/amba-pl011.c | 32 +++ > > drivers/tty/serial/kgdboc.c | 268 ++++++++++++++++-- > > drivers/tty/serial/qcom_geni_serial.c | 32 +++ > > include/linux/kgdb.h | 4 + > > kernel/debug/debug_core.c | 52 +++- > > lib/Kconfig.kgdb | 18 ++ > > 14 files changed, 436 insertions(+), 46 deletions(-) > > Any thoughts on how best to land these changes? > > AFAICT the arm64 I was hoping to get an Ack from Will or Catalin for my most recent arm64 patch [1] and then it could land in your tree. However, it wouldn't be the end of the world if that landed later. "kgdbwait" would be broken if you used it together with "kgdb_earlycon" but overall we'd still be in a better place than we were. > and 8250/amba-pl011/qcom_geni_serial code > could be applied independently of the kgdb changes Right, that would be OK. Nobody would actually be able to use "kgdb_earlycon" until those landed but there would be no problem with those two landing separately. > (though we must keep > changes to drivers/tty/serial/kgdboc alongside the kgdb changes). > > I can hoover them up but I'd need a solid set of acks and > I don't think we've got that yet. It would be nice for it to be explicit, but "get_maintainer" says that Greg KH is the maintainer of serial drivers. Git log confirms that he also has been the one landing changes to these files. Early-on he provided his Reviewed-by for the series as a whole, so he's aware of it and maybe would be fine w/ the serial changes landing through the kgdb tree? Greg: is that correct? > I'd also be happy to ack where needed and let someone else pick it up > (the other changes queued for kgdb this cycle are pretty small so we > shouldn't see much conflict in kernel/debug/ ). It feels to me that the kgdb tree is the best destination for all these patches if possible. [1] https://lore.kernel.org/r/20200513160501.1.I0b5edf030cc6ebef6ab4829f8867cdaea42485d8@changeid -Doug
On Thu, May 14, 2020 at 09:34:26AM -0700, Doug Anderson wrote: > > (though we must keep > > changes to drivers/tty/serial/kgdboc alongside the kgdb changes). > > > > I can hoover them up but I'd need a solid set of acks and > > I don't think we've got that yet. > > It would be nice for it to be explicit, but "get_maintainer" says that > Greg KH is the maintainer of serial drivers. Git log confirms that he > also has been the one landing changes to these files. Early-on he > provided his Reviewed-by for the series as a whole, so he's aware of > it and maybe would be fine w/ the serial changes landing through the > kgdb tree? > > Greg: is that correct? I have no objection for all of these to go through any other tree that wants to take them :) But if you want me to take them in the serial tree, to make it easier for you or any other serial driver issues, I will be glad to do that, just send them my way. It's your call. thanks, greg k-h
On Thu, May 07, 2020 at 01:08:38PM -0700, Douglas Anderson wrote: > This whole pile of patches was motivated by me trying to get kgdb to > work properly on a platform where my serial driver ended up being hit > by the -EPROBE_DEFER virus (it wasn't practicing social distancing > from other drivers). Specifically my serial driver's parent device > depended on a resource that wasn't available when its probe was first > called. It returned -EPROBE_DEFER which meant that when "kgdboc" > tried to run its setup the serial driver wasn't there. Unfortunately > "kgdboc" never tried again, so that meant that kgdb was disabled until > I manually enalbed it via sysfs. > > <snip> > > This series (and my comments / documentation / commit messages) are > now long enough that my eyes glaze over when I try to read it all over > to double-check. I've nontheless tried to double-check it, but I'm > pretty sure I did something stupid. Thank you ahead of time for > pointing it out to me so I can fix it in v5. If somehow I managed to > not do anything stupid (really?) then thank you for double-checking me > anyway. Applied (minus the arm64 specific stuff), should be in the next linux-next. Daniel.
On Thu, May 14, 2020 at 06:36:33PM +0200, Greg Kroah-Hartman wrote: > On Thu, May 14, 2020 at 09:34:26AM -0700, Doug Anderson wrote: > > > (though we must keep > > > changes to drivers/tty/serial/kgdboc alongside the kgdb changes). > > > > > > I can hoover them up but I'd need a solid set of acks and > > > I don't think we've got that yet. > > > > It would be nice for it to be explicit, but "get_maintainer" says that > > Greg KH is the maintainer of serial drivers. Git log confirms that he > > also has been the one landing changes to these files. Early-on he > > provided his Reviewed-by for the series as a whole, so he's aware of > > it and maybe would be fine w/ the serial changes landing through the > > kgdb tree? > > > > Greg: is that correct? > > I have no objection for all of these to go through any other tree that > wants to take them :) > > But if you want me to take them in the serial tree, to make it easier > for you or any other serial driver issues, I will be glad to do that, > just send them my way. It's your call. Thanks. I've taken then via my tree. Daniel.