Skip to content

serial: Finish sysrq on qcom_geni; fix sysrq vs. lockdep on 8250

Andy Shevchenko linux-arm-kernel linux-arm-msm linux-aspeed linux-serial 2 versions New

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v2 Latest posting 2/20 of 5 patches 0 repliesNew
  2. v2 posting 1/20 of 5 patches 0 repliesSuperseded

Patches in v2 posting 2/2 No applies recorded yet

None of the 5 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.

Read the v2 thread

Cover letter [PATCH v2 0/5] serial: Finish sysrq on qcom_geni; fix sysrq vs. lockdep on 8250
Quoted 33 lines · Doug Anderson

Hi,

Quoted 29 lines · Andy Shevchenko
Quoted 26 lines · Douglas Anderson

I started out this series trying to make sysrq work over the serial console on qcom_geni_serial, then fell into a rat's nest.

To solve the deadlock I faced when enabling sysrq I tried to borrow code from '8250_port.c' which avoided grabbing the port lock in console_write(). ...but since these days I try to run with lockdep on all the time, I found it caused an annoying lockdep splat (which I also reproduced on my rk3399 board). ...so I instead changed my qcom_geni_serial solution to borrow code from 'msm_serial.c'

I wasn't super happy with the solution in 'msm_serial.c' though. I don't like releasing the spinlock there. Not only is it ugly but it means we are unlocking / re-locking _all the time_ even though sysrq characters are rare. ...so I came up with what I think is a better solution and then implemented it for qcom_geni_serial.

Since I had a good way to test 8250-based UARTs, I also fixed that driver to use my new method. When doing so, I ran into a missing include in serial_core.h. NOTE: I didn't have a way to test msm_serial.c at all, so I didn't switch that (or all other serial drivers for that matter) to the new method.

NOTE: from a serial point of view v2 is the same as v1 but I've removed the extra kgdb-related patches and made it obvious that this is really for all sysrq, not just kgdb. I've also generally tried to curate the CCs more properly.

Quoted 4 lines
Quoted 1 line

It seems your forgot console people to Cc.

Can you be more specific, please? Which section of the "MAINTAINERS" file should I be looking at for the "console" you are thinking of?

I have added them to Cc list: Petr, Sergey, and Steven.

Quoted 5 lines

Certainly there are lots of hits for "console" in MAINTAINERS but I don't think I see any that are relevant that I missed. Grepping:

Ah! Based on who you added to the CC list I guess you meant to CC "printk" folks?

Correct.

Quoted 9 lines

PRINTK

M:      Petr Mladek <[email protected]>
M:      Sergey Senozhatsky <[email protected]>
R:      Steven Rostedt <[email protected]>
S:      Maintained
F:      kernel/printk/
F:      include/linux/printk.h
Quoted 4 lines

I'd be happy to CC those folks on future spins (if there are any). I'm not convinced that these patches are directly relevant to the printk subsystem, but I'm always happy for more people to have a chance to review patches.

If you look retrospectively in the mailing lists, you can find that they are doing most of the console core work, which I believe includes SysRq behaviour. So, don't be confused their names are listed under PRINTK.

Quoted 5 lines

Hopefully anyone who needs this patch can find it on one of the relevant mailing lists. I screwed up and missed LKML this time around, but there are plenty of other mailing lists here that it could be found on. If requested I'm also happy to re-post the same series adding those 3 people if that's what everyone wants.

Signature · 2 lines
With Best Regards,
Andy Shevchenko

Read the cover letter in its thread