| Message ID | 20230914183831.587273-1-john.ogness@linutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | serial: wrappers for uart port lock | expand |
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? Maciej
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 Fri, 15 Sep 2023, Thomas Gleixner 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. Ah, right, that's because there are registers shared between two ports within one SCC, so the spinlock has to be shared as well. This also indicates that dz.c is wrong and shouldn't be using a per-port spinlock as the DZ has a shared register set between all the four ports (it's a serial line multiplexer rather than a set discrete ports; up to 8 lines are architecturally supported, though we don't have support in Linux for systems having those), e.g. there's only one 16-bit receiver buffer register for all the four ports, supplying the 8-bit character received along with the receive status and the number of the line this data arrived on, and similarly there's only one transmit data register, which supplies data to the next enabled line whose transmit buffer needs servicing, and the chip routes the data itself. Therefore the driver ought to use a shared spinlock too. I guess it wasn't noticed so far because DZ devices aren't that common (and my usual test machine is currently broken too, pending an SRAM chip replacement, hopefully in the next few weeks) and then hardly ever more than one serial line has been used at a time with these devices. It looks like the first issue for me to look into once the machine has been fixed. Maybe dz.c shouldn't be touched by this series then? (Though obviously both drivers will have to be eventually adapted for the ultimate console rework.) Thanks for your input, as it turns out it has had an unexpected outcome. Maciej
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