| Message ID | 20230914183831.587273-1-john.ogness@linutronix.de |
|---|---|
| Headers | show |
| Series | serial: wrappers for uart port lock | expand |
On Thu, 14 Sep 2023, John Ogness wrote: > When a serial port is used for kernel console output, then all > modifications to the UART registers which are done from other contexts, > e.g. getty, termios, are interference points for the kernel console. > > So far this has been ignored and the printk output is based on the > principle of hope. The rework of the console infrastructure which aims to > support threaded and atomic consoles, requires to mark sections which > modify the UART registers as unsafe. This allows the atomic write function > to make informed decisions and eventually to restore operational state. It > also allows to prevent the regular UART code from modifying UART registers > while printk output is in progress. Hi John, Would this also be useful to enable printing to console while under port's lock (by postponing the output until the lock is released)? E.g., 8250_dw.c has had this commented out since the dawn on time: /* * FIXME: this deadlocks if port->lock is already held * dev_err(p->dev, "Couldn't set LCR to %d\n", value); */
On Thu, Sep 14 2023 at 20:01, Maciej W. Rozycki wrote: > On Thu, 14 Sep 2023, John Ogness wrote: > >> Patches 2-74 switch all uart port locking call sites to use the new >> wrappers. These patches were automatically generated using coccinelle. > > Hmm, no need to do this for drivers/tty/serial/zs.c? zs.c does not use port lock at all. It has like a couple of other drivers a local homebrewn spinlock. Thanks, tglx
On 2023-09-15, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote: > Maybe dz.c shouldn't be touched by this series then? Correct. This series is only wrapping the uart port lock, which dz.c is not using. > Though obviously both drivers will have to be eventually adapted for > the ultimate console rework. Correct. Thanks for clarifying how the hardware works. John
On 2023-09-15, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote: > Would this also be useful to enable printing to console while under > port's lock (by postponing the output until the lock is released)? > > E.g., 8250_dw.c has had this commented out since the dawn on time: > /* > * FIXME: this deadlocks if port->lock is already held > * dev_err(p->dev, "Couldn't set LCR to %d\n", value); > */ Yes, this will fix such issues. However, only for consoles that are converted to the new NBCON console type. Good news, the 8250 driver will be the flagship driver that is converted as part of the rework. So this particular issue will be solved then. I will try to remember this so that I can remove the FIXME in the series. Thanks for mentioning it. John
On 2023-09-14, John Ogness <john.ogness@linutronix.de> wrote: > Provide and use wrapper functions for spin_[un]lock*(port->lock) > invocations so that the console mechanics can be applied later on at a > single place and does not require to copy the same logic all over the > drivers. For the full 74-patch series: Signed-off-by: John Ogness <john.ogness@linutronix.de> Sorry that my SoB was missing from the initial posting. John Ogness
On Mon, Sep 18, 2023 at 10:29:30AM +0206, John Ogness wrote: > On 2023-09-14, John Ogness <john.ogness@linutronix.de> wrote: > > Provide and use wrapper functions for spin_[un]lock*(port->lock) > > invocations so that the console mechanics can be applied later on at a > > single place and does not require to copy the same logic all over the > > drivers. > > For the full 74-patch series: > > Signed-off-by: John Ogness <john.ogness@linutronix.de> > > Sorry that my SoB was missing from the initial posting. Thanks for this, I'll rebuild my tree with this added. greg k-h