Re: [PATCH 0/2] braille: nbcon: Allow using a serial driver converted to nbcon API as a Braille console

From: Petr Mladek

Date: Tue Sep 29 2026 - 08:54:37 EST


On Fri 2026-09-25 21:11:41, John Ogness wrote:
> On 2026-09-25, Petr Mladek <pmladek@xxxxxxxx> wrote:
> > I used on the command line:
> >
> > console=brl,ttyS0,115200 console=tty0
> >
> > The serial console driver is not in console_list. But it shows
> > all printk() messages because tty0 is in console_list and
> > the messages are shown there.
>
> Got it. So from the perspective of printk() we have a legacy
> console. The legacy console is (mis)using the write callback of a
> console driver to write to the underlying device. And since the driver
> for the underlying device is NBCON, these contexts do not match. But
> actually it is more complicated than that, because the console driver
> callback is being used for all vt updates, not just those from printk().

Yes. This looks like a good description of the situation.

> Since the 8250 driver (and so far all NBCON UART drivers) use the port
> lock for the ->device_lock() callback, it would be enough to do:
>
> con->device_lock();
> con->write_thread();
> con->device_unlock();

I'll play with this and use it in v3 when the code looks reasonable.
I'll try to get the nbcon context as well. It will be for !PREEMPT_RT anyway.

> if it is NBCON. That would at least provide proper locking (port lock)
> for the underlying device during runtime. The only downside is that
> panic could deadlock if the panic occurred while a CPU is holding the
> port lock.

Yup, we would need some special handling in panic and rely just on
the nbcon context.

Best Regards,
Petr