On 2023-09-14, John Ogness 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
On 2023-09-15, Ilpo Järvinen 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 p
On 2023-09-15, "Maciej W. Rozycki" 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.
Tha
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 rewo
From: Thomas Gleixner
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
pri
the boot arguments of
users that are not experiencing problems may help to reveal some of the
unusual console usages until now.
John Ogness
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/li
