Re: [PATCH tty v9 1/2] serial: 8250: Switch to nbcon console, take 2

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, Aug 18, 2026 at 06:32:12AM +0100, Jon Hunter wrote:
> On 24/07/2026 11:36, John Ogness wrote:
> > Implement the necessary callbacks to switch the 8250 console driver
> > to perform as an nbcon console.
> > 
> > Add implementations for the nbcon console callbacks:
> > 
> >    ->write_atomic()
> >    ->write_thread()
> >    ->device_lock()
> >    ->device_unlock()
> > 
> > and add CON_NBCON to the initial @flags.
> > 
> > All hardware access in the callbacks is within unsafe sections.
> > The ->write_atomic() and ->write_thread() callbacks allow safe
> > handover/takeover per byte and add a preceding newline if they
> > take over from another context mid-line.
> > 
> > For the ->write_atomic() callback, a new irq_work is used to defer
> > modem control since it may be called from a context that does not
> > allow waking up tasks. During suspend/resume the irq_work is not
> > used as this has been shown to cause suspend problems for some
> > hardware. Upon resume, any pending modem control is performed.
> > 
> > Note: A new __serial8250_clear_IER() is introduced for direct
> > clearing of UART_IER during console writing (which will not be
> > holding the port lock for atomic printing or KDB/KGDB). This
> > allows restoring a lockdep check to serial8250_clear_IER() in
> > a follow-up commit.
> 
> This change is causing a boot regression for our Tegra20 and Tegra30
> platforms. Reverting this on top of -next fixes the issue. Previously with
> V5 I did not see a boot issue only an issue in suspend.

Wasn't v11 applied and not v9?

> So far the only
> interesting thing I have observed is that if I add 'keep_bootcon' to the
> command line the board does boot.

keep_bootcon defers driver taking over, that's why it works, it uses just
simple primitives instead of full-featured driver.

-- 
With Best Regards,
Andy Shevchenko