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

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

[Petr Mladek]

Hi,

I have been working on v5 [1] of the patchset cleaning console registration
code and I found that the system did not boot when I selected a Braille
on the command line, for example:

     console=brl,ttyS0,115200 console=tty0

Bisection went down to the commit d3539347022a ("serial: 8250: Switch to
nbcon console, take 2"). I found that the Braille console driver called
braille_co->write() internally where braille_co pointed to the uart
8250 driver.

I added the support for the nbcon console API similar way as we did
for kdb [2].

Note 1: I believe that we have a bug in the kdb patch because we call
        con->write() atomic callback after entering the unsafe mode.
        But we should do so in the default "safe" mode.

Note 2: I am not completely sure about the locking. It might be better
        to use NBCON_PRIO_PANIC in panic().

        Also I thought about using con->write_thread(). But I think
	that we have to use the atomic variant because the Braille
	console can be called from printk() via the VT code, aka
	graphical console.

Note 3: I do not have any device to read the Braille output so I am not
	sure if the output is correct. I just checked the output on
	the serial console and it is a bit suspicious. It looks like
	it prints every message N-times when N is the length of the string.
	And it adds one character in each iteration, for example:

<paste>
E>[                                       E>[                                       E>[  O                                    *>[  OK                                   A>[  OK                                   A>[  OK                                   A>[  OK  ]                                <>[  OK  ]                                <>[  OK  ] R                              N>[  OK  ] Re                             
       >[  OK  ] Rea                            J>[  OK  ] Reac                           	>[  OK  ] Reach                          A>[  OK  ] Reache                         D>[  OK  ] Reached                        @>[  OK  ] Reached                        @>[  OK  ] Reached t           
</paste>

	But I think that this is not caused by the NBCON console API.

[1] https://lore.kernel.org/all/20260604101459.393162-1-pmladek@suse.com/
[2] https://lore.kernel.org/all/20251016-nbcon-kgdboc-v6-0-866aac60a80e@suse.com/

Petr Mladek (2):
  printk: nbcon: Introduce Braille helpers
  braille: nbcon: Use nbcon atomic console callbacks

 .../accessibility/braille/braille_console.c   | 38 +++++++++++-
 drivers/tty/serial/8250/8250_port.c           |  5 +-
 include/linux/console.h                       |  8 +++
 kernel/printk/nbcon.c                         | 59 +++++++++++++++++++
 4 files changed, 107 insertions(+), 3 deletions(-)

-- 
2.55.0

[PATCH 1/2] printk: nbcon: Introduce Braille helpers

[Petr Mladek]

These helpers will be used when calling console->write_atomic
in the Braille console driver.

The Braille console is not registered as a standard printk console.
Instead, it is integrated with the virtual terminal (VT) and writes
data using the legacy con->write() callback of the associated serial
console driver.

When the underlying console driver is converted to the NBCON API, the
Braille console needs to use the con->write_atomic() callback instead.
This callback must be synchronized by acquiring the nbcon console context.

Fixes: d3539347022a ("serial: 8250: Switch to nbcon console, take 2")
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
 include/linux/console.h |  8 ++++++
 kernel/printk/nbcon.c   | 59 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+)

diff --git a/include/linux/console.h b/include/linux/console.h
index 502d1abe3f50..d780f6de303a 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -615,6 +615,10 @@ extern bool nbcon_allow_unsafe_takeover(void);
 extern bool nbcon_kdb_try_acquire(struct console *con,
 				  struct nbcon_write_context *wctxt);
 extern void nbcon_kdb_release(struct nbcon_write_context *wctxt);
+extern bool nbcon_is_braille(struct nbcon_write_context *wctxt);
+extern bool nbcon_braille_try_acquire(struct console *con,
+				      struct nbcon_write_context *wctxt);
+extern void nbcon_braille_release(struct nbcon_write_context *wctxt);
 
 /*
  * Check if the given console is currently capable and allowed to print
@@ -678,8 +682,12 @@ static inline void nbcon_reacquire_nobuf(struct nbcon_write_context *wctxt) { }
 static inline bool nbcon_kdb_try_acquire(struct console *con,
 					 struct nbcon_write_context *wctxt) { return false; }
 static inline void nbcon_kdb_release(struct nbcon_write_context *wctxt) { }
+static inline bool nbcon_is_braille(struct nbcon_write_context *wctxt) { return false; }
 static inline bool console_is_usable(struct console *con, short flags,
 				     bool use_atomic) { return false; }
+static inline bool nbcon_braille_try_acquire(struct console *con,
+					     struct nbcon_write_context *wctxt) { return false; }
+static inline void nbcon_braille_release(struct nbcon_write_context *wctxt) { }
 #endif
 
 extern int console_set_on_cmdline;
diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
index d17704fe93ae..a5e053ffe4da 100644
--- a/kernel/printk/nbcon.c
+++ b/kernel/printk/nbcon.c
@@ -2002,3 +2002,62 @@ void nbcon_kdb_release(struct nbcon_write_context *wctxt)
 	 */
 	__nbcon_atomic_flush_pending_con(ctxt->console, prb_next_reserve_seq(prb));
 }
+
+/**
+ * nbcon_is_braille - Checks whether the nbcon write context is using Braille console
+ *
+ * @wctxt:	checked nbcon write context
+ *
+ * Return: True when the write context is associated with a Braille console.
+ *	   Othrewise, return false.
+ *
+ * Context: Can be called in any context but only when Braille console is
+ *	registered and the struct console could not disappear.
+ */
+bool nbcon_is_braille(struct nbcon_write_context *wctxt)
+{
+	struct nbcon_context *ctxt = &ACCESS_PRIVATE(wctxt, ctxt);
+	struct console *con = ctxt->console;
+
+	return con && con->flags & CON_BRL;
+}
+
+/**
+ * nbcon_braille_try_acquire - Try to acquire nbcon console for braille_write()
+ *
+ * @con:	The nbcon console to acquire
+ * @wctxt:	The nbcon write context to be used on success
+ *
+ * Context:	braille_write() for emitting a single buffer on Braille console.
+ *
+ * Return:	True if the console was acquired. False otherwise.
+ *
+ * Braille console is not registered as a proper printk consoles. Instead,
+ * it is integrated with the graphical virtual terminal.
+ *
+ * This function acquires the nbcon console using priority NBCON_PRIO_EMERGENCY.
+ */
+bool nbcon_braille_try_acquire(struct console *con,
+			   struct nbcon_write_context *wctxt)
+{
+	struct nbcon_context *ctxt = &ACCESS_PRIVATE(wctxt, ctxt);
+
+	memset(ctxt, 0, sizeof(*ctxt));
+	ctxt->console = con;
+	ctxt->prio    = NBCON_PRIO_EMERGENCY;
+
+	return nbcon_context_try_acquire(ctxt, false);
+}
+
+/**
+ * nbcon_braille_release - Release the nbcon console
+ *
+ * @wctxt:	The nbcon write context initialized by a successful
+ *		nbcon_braille_try_acquire()
+ */
+void nbcon_braille_release(struct nbcon_write_context *wctxt)
+{
+	struct nbcon_context *ctxt = &ACCESS_PRIVATE(wctxt, ctxt);
+
+	nbcon_context_release(ctxt);
+}
-- 
2.55.0

[PATCH 2/2] braille: nbcon: Use nbcon atomic console callbacks

[Petr Mladek]

The Braille console is integrated with the virtual terminal (VT) and
writes its data using the legacy con->write() callback of the associated
serial console driver.

However, once the underlying console driver is converted to the NBCON
API, it should use the con->write_atomic() callback, which must be
synchronized by acquiring the nbcon console context.

Adapt braille_write() to handle NBCON consoles:

1. Acquire the nbcon console ownership using NBCON_PRIO_EMERGENCY
   priority before printing, disabling local interrupts to prevent
   any nested calls into the driver.
2. Call the con->write_atomic() callback to write the buffer.
3. Release the nbcon console ownership and restore local interrupts.

Also, adjust __serial8250_console_write() in the 8250 serial driver to
exclude Braille consoles from the newline prepending logic. The serial
port is not used for standard printk logging which might be interrupted
in the middle of the operation. In the Braille mode, the serial driver
is supposed to write exactly what it gets. In fact, it does not print
any newlines at all in this case.

Fixes: d3539347022a ("serial: 8250: Switch to nbcon console, take 2")
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
 .../accessibility/braille/braille_console.c   | 38 ++++++++++++++++++-
 drivers/tty/serial/8250/8250_port.c           |  5 ++-
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/accessibility/braille/braille_console.c b/drivers/accessibility/braille/braille_console.c
index 06b43b678d6e..cd1019d478db 100644
--- a/drivers/accessibility/braille/braille_console.c
+++ b/drivers/accessibility/braille/braille_console.c
@@ -62,14 +62,32 @@ static void braille_write(u16 *buf)
 {
 	static u16 lastwrite[WIDTH];
 	unsigned char data[1 + 1 + 2*WIDTH + 2 + 1], csum = 0, *c;
+	struct nbcon_write_context wctxt = { };
+	unsigned long flags;
+
 	u16 out;
 	int i;
 
 	if (!braille_co)
 		return;
 
+	if (braille_co->flags & CON_NBCON) {
+		/*
+		 * Braille console might be called from unknown context via
+		 * vt_console_print() from console_unlock() from printk().
+		 * Use the atomic callback and synchronize it just using
+		 * the console context. Disable interrupts to prevent a nested
+		 * call into the driver code which might cause a deadlock when
+		 * trying to acquire the console ownership, see
+		 * __nbcon_atomic_flush_pending_con().
+		 */
+		local_irq_save(flags);
+		while (!nbcon_braille_try_acquire(braille_co, &wctxt))
+			cpu_relax();
+	}
+
 	if (!memcmp(lastwrite, buf, WIDTH * sizeof(*buf)))
-		return;
+		goto release_nbcon;
 	memcpy(lastwrite, buf, WIDTH * sizeof(*buf));
 
 #define SOH 1
@@ -102,7 +120,23 @@ static void braille_write(u16 *buf)
 	*c++ = csum;
 	*c++ = ETX;
 
-	braille_co->write(braille_co, data, c - data);
+	if (braille_co->flags & CON_NBCON) {
+		if (braille_co->write_atomic &&
+		    !braille_co->flags & CON_NBCON_ATOMIC_UNSAFE) {
+			nbcon_write_context_set_buf(&wctxt, (char *)data, c - data);
+			braille_co->write_atomic(braille_co, &wctxt);
+		} else {
+			pr_warn_once("Braille requires a safe braille_co->write_atomic callback\n");
+		}
+	} else {
+		braille_co->write(braille_co, data, c - data);
+	}
+
+release_nbcon:
+	if (braille_co->flags & CON_NBCON) {
+		nbcon_braille_release(&wctxt);
+		local_irq_restore(flags);
+	}
 }
 
 /* Follow the VC cursor*/
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 38fa45e74a37..6eb0b439e433 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -3417,8 +3417,11 @@ static void __serial8250_console_write(struct uart_8250_port *up,
 	 * If the console printer did not fully output the previous line, it
 	 * must have been handed or taken over. Insert a newline in order to
 	 * maintain clean output.
+	 *
+	 * Braille consoles are an exception. The serial port is not used
+	 * for printk(). The driver is supposed to write exactly what it gets.
 	 */
-	if (!up->console_line_ended) {
+	if (unlikely(!up->console_line_ended && !nbcon_is_braille(wctxt))) {
 		if (use_fifo)
 			__serial8250_console_fifo_write(up, wctxt, "\n", 1);
 		else
-- 
2.55.0

Re: [PATCH 2/2] braille: nbcon: Use nbcon atomic console callbacks

[Petr Mladek]

On Tue 2026-09-22 07:37:27, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] braille: operator precedence bug disables braille atomic write
> - [High] braille: infinite spinlock in braille_write() during same-CPU unsafe takeover
> --
> 
> commit a7f38c0383481bd6ad9c244405d8d201d604569b
> Author: Petr Mladek <pmladek@suse.com>
> 
> braille: nbcon: Use nbcon atomic console callbacks
> 
> This commit adapts the braille console driver to support the new NBCON API.
> It introduces logic to acquire the nbcon console ownership before printing
> and uses the atomic write callback to output the buffer. The serial8250
> driver is also adjusted to skip prepending newlines for braille consoles.
> 
> > diff --git a/drivers/accessibility/braille/braille_console.c b/drivers/accessibility/braille/braille_console.c
> > --- a/drivers/accessibility/braille/braille_console.c
> > +++ b/drivers/accessibility/braille/braille_console.c
> > @@ -62,14 +62,32 @@ static void braille_write(u16 *buf)
> 
> [ ... ]
> 
> > +	if (braille_co->flags & CON_NBCON) {
> > +		/*
> > +		 * Braille console might be called from unknown context via
> > +		 * vt_console_print() from console_unlock() from printk().
> > +		 * Use the atomic callback and synchronize it just using
> > +		 * the console context. Disable interrupts to prevent a nested
> > +		 * call into the driver code which might cause a deadlock when
> > +		 * trying to acquire the console ownership, see
> > +		 * __nbcon_atomic_flush_pending_con().
> > +		 */
> > +		local_irq_save(flags);
> > +		while (!nbcon_braille_try_acquire(braille_co, &wctxt))
> > +			cpu_relax();
> 
> [Severity: High]
> Could this loop become an infinite spinlock if triggered from a nested
> context on the same CPU?
> 
> If an interrupt preempts the underlying nbcon console driver (such as 8250)
> while it is in an unsafe region, and that interrupt triggers a printk(),
> the legacy VT console might be flushed via console_unlock(), eventually
> calling braille_write().
> 
> Since local interrupts are disabled here, the preempted nbcon context on
> this same CPU can never resume to release the console. Because
> nbcon_context_try_acquire() rejects handovers to the same CPU when the
> console is in an unsafe state, won't this loop spin indefinitely?

For me, it is not easy to be sure but it looks to me that this code
is called deep in the generic vt code when handling vt_notifier_list
and keyboard_notifier_list. I guess that they already have to
synchronized against each other. At least the vt_notifier_list
operations seem to be synchronized using the console lock.

Anyway, the disabled interrupts should prevent nesting except
by NMI. But I believe that the VT code should not be called
in NMI because it uses locks. The only exception might be
panic().

An improvement might be to use NBCON_PRIO_PANIC in panic.
Something like (on top of 1st patch):

--- a/kernel/printk/nbcon.c
+++ b/kernel/printk/nbcon.c
@@ -2044,7 +2044,14 @@ bool nbcon_braille_try_acquire(struct console *con,
 
 	memset(ctxt, 0, sizeof(*ctxt));
 	ctxt->console = con;
-	ctxt->prio    = NBCON_PRIO_EMERGENCY;
+	ctxt->prio = nbcon_get_default_prio();
+
+	/*
+	 * The Braille console might be used in an interrupt context but
+	 * NBCON_PRIO_EMERGENCY is associated with task context.
+	 */
+	if (ctxt->prio < NBCON_PRIO_EMERGENCY)
+		ctxt->prio = NBCON_PRIO_EMERGENCY;
 
 	return nbcon_context_try_acquire(ctxt, false);
 }

> [ ... ]
> 
> > -	braille_co->write(braille_co, data, c - data);
> > +	if (braille_co->flags & CON_NBCON) {
> > +		if (braille_co->write_atomic &&
> > +		    !braille_co->flags & CON_NBCON_ATOMIC_UNSAFE) {
> 
> [Severity: High]
> Does this operator precedence evaluate as intended?
> 
> Because the logical not (!) operator has higher precedence than the bitwise
> and (&) operator, this expression parses as:
> 
> (!braille_co->flags) & CON_NBCON_ATOMIC_UNSAFE
> 
> Since braille_co->flags is known to be non-zero (as CON_NBCON was just
> checked above), evaluating the logical not against the flags yields 0. This
> makes the condition permanently false, which bypasses the braille atomic
> write callback unconditionally.
> 
> Should this be grouped with parentheses to evaluate the bitwise and first?

Grr, sure, it should be:

		    !(braille_co->flags & CON_NBCON_ATOMIC_UNSAFE)) {

I'll fix this in v2.

I am going to wait with v2 a bit just in case anyone would like to
comment on v1...

Best Regards,
Petr

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

[Samuel Thibault]

Hello,

Petr Mladek, le mar. 22 sept. 2026 09:25:56 +0200, a ecrit:
> Note 3: I do not have any device to read the Braille output so I am not
> 	sure if the output is correct. I just checked the output on
> 	the serial console and it is a bit suspicious. It looks like
> 	it prints every message N-times when N is the length of the string.
> 	And it adds one character in each iteration, for example:

That is actually expected: braille displays don't show the whole log of
what was printed, it only shows the last print. Getting it printed on
each character output is expected if characters are printed one by one,
the device will show the text as it gets printed.

Thanks for fixing this!

With regards,
Samuel

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

[John Ogness]

On 2026-09-22, Petr Mladek <pmladek@suse.com> wrote:
> I have been working on v5 [1] of the patchset cleaning console registration
> code and I found that the system did not boot when I selected a Braille
> on the command line, for example:
>
>      console=brl,ttyS0,115200 console=tty0
>
> Bisection went down to the commit d3539347022a ("serial: 8250: Switch to
> nbcon console, take 2"). I found that the Braille console driver called
> braille_co->write() internally where braille_co pointed to the uart
> 8250 driver.

The Braille console blindly calling (struct console).write() is
obviously bad. This needs to be fixed. And not just because of the
8250. Other NBCON drivers already exist mainline and have this same
issue.

> I added the support for the nbcon console API similar way as we did
> for kdb [2].

kdb does not need to care about latencies. The Braille consoles do. I
will comment more on this in the related patch.

> Note 1: I believe that we have a bug in the kdb patch because we call
>         con->write() atomic callback after entering the unsafe mode.
>         But we should do so in the default "safe" mode.

Why do you believe this? kdb operates within an unsafe section so that
other CPUs cannot take ownership. (BTW: For kdb the other CPUs are
supposed to be quiesced, so there should not be any ownership attempts
anyway. The unsafe section is just an extra precaution.)

> Note 2: I am not completely sure about the locking. It might be better
>         to use NBCON_PRIO_PANIC in panic().

Why does it matter? printk() is not trying to do any Braille printing
during panic, so it will not attempt to acquire the Braille console.

>       Also I thought about using con->write_thread(). But I think
> 	that we have to use the atomic variant because the Braille
> 	console can be called from printk() via the VT code, aka
> 	graphical console.

How can it be called from printk()? Even printk() writing to VT is only
if it is registered as a console. Braille consoles are not registered.
Please explain.

Note that ->write_thread() is the only NBCON callback guaranteed to
exist.

John

Re: [PATCH 1/2] printk: nbcon: Introduce Braille helpers

[John Ogness]

On 2026-09-22, Petr Mladek <pmladek@suse.com> wrote:
> These helpers will be used when calling console->write_atomic
> in the Braille console driver.
>
> The Braille console is not registered as a standard printk console.
> Instead, it is integrated with the virtual terminal (VT) and writes
> data using the legacy con->write() callback of the associated serial
> console driver.
>
> When the underlying console driver is converted to the NBCON API, the
> Braille console needs to use the con->write_atomic() callback instead.
> This callback must be synchronized by acquiring the nbcon console context.
>
> Fixes: d3539347022a ("serial: 8250: Switch to nbcon console, take 2")

This is not 8250 specific. But I am not sure which commit you want to
mark as Fixes.

For 62627bf0cadf ("kdb: Adapt kdb_msg_write to work with NBCON
consoles") there was no Fixes tag.

> Signed-off-by: Petr Mladek <pmladek@suse.com>
> ---
>  include/linux/console.h |  8 ++++++
>  kernel/printk/nbcon.c   | 59 +++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 67 insertions(+)
>
> diff --git a/include/linux/console.h b/include/linux/console.h
> index 502d1abe3f50..d780f6de303a 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -615,6 +615,10 @@ extern bool nbcon_allow_unsafe_takeover(void);
>  extern bool nbcon_kdb_try_acquire(struct console *con,
>  				  struct nbcon_write_context *wctxt);
>  extern void nbcon_kdb_release(struct nbcon_write_context *wctxt);
> +extern bool nbcon_is_braille(struct nbcon_write_context *wctxt);
> +extern bool nbcon_braille_try_acquire(struct console *con,
> +				      struct nbcon_write_context *wctxt);
> +extern void nbcon_braille_release(struct nbcon_write_context *wctxt);
>  
>  /*
>   * Check if the given console is currently capable and allowed to print
> @@ -678,8 +682,12 @@ static inline void nbcon_reacquire_nobuf(struct nbcon_write_context *wctxt) { }
>  static inline bool nbcon_kdb_try_acquire(struct console *con,
>  					 struct nbcon_write_context *wctxt) { return false; }
>  static inline void nbcon_kdb_release(struct nbcon_write_context *wctxt) { }
> +static inline bool nbcon_is_braille(struct nbcon_write_context *wctxt) { return false; }
>  static inline bool console_is_usable(struct console *con, short flags,
>  				     bool use_atomic) { return false; }
> +static inline bool nbcon_braille_try_acquire(struct console *con,
> +					     struct nbcon_write_context *wctxt) { return false; }
> +static inline void nbcon_braille_release(struct nbcon_write_context *wctxt) { }
>  #endif
>  
>  extern int console_set_on_cmdline;
> diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> index d17704fe93ae..a5e053ffe4da 100644
> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -2002,3 +2002,62 @@ void nbcon_kdb_release(struct nbcon_write_context *wctxt)
>  	 */
>  	__nbcon_atomic_flush_pending_con(ctxt->console, prb_next_reserve_seq(prb));
>  }
> +
> +/**
> + * nbcon_is_braille - Checks whether the nbcon write context is using Braille console
> + *
> + * @wctxt:	checked nbcon write context
> + *
> + * Return: True when the write context is associated with a Braille console.
> + *	   Othrewise, return false.
> + *
> + * Context: Can be called in any context but only when Braille console is
> + *	registered and the struct console could not disappear.
> + */
> +bool nbcon_is_braille(struct nbcon_write_context *wctxt)
> +{
> +	struct nbcon_context *ctxt = &ACCESS_PRIVATE(wctxt, ctxt);
> +	struct console *con = ctxt->console;
> +
> +	return con && con->flags & CON_BRL;
> +}
> +
> +/**
> + * nbcon_braille_try_acquire - Try to acquire nbcon console for braille_write()
> + *
> + * @con:	The nbcon console to acquire
> + * @wctxt:	The nbcon write context to be used on success
> + *
> + * Context:	braille_write() for emitting a single buffer on Braille console.
> + *
> + * Return:	True if the console was acquired. False otherwise.
> + *
> + * Braille console is not registered as a proper printk consoles. Instead,
> + * it is integrated with the graphical virtual terminal.
> + *
> + * This function acquires the nbcon console using priority NBCON_PRIO_EMERGENCY.
> + */
> +bool nbcon_braille_try_acquire(struct console *con,
> +			   struct nbcon_write_context *wctxt)
> +{
> +	struct nbcon_context *ctxt = &ACCESS_PRIVATE(wctxt, ctxt);
> +
> +	memset(ctxt, 0, sizeof(*ctxt));
> +	ctxt->console = con;
> +	ctxt->prio    = NBCON_PRIO_EMERGENCY;
> +
> +	return nbcon_context_try_acquire(ctxt, false);
> +}

This is really the same thing as nbcon_kdb_try_acquire().

As you mentioned in your cover letter, it is a bug that
nbcon_kdb_try_acquire() enters an unsafe section because @unsafe is a
bool rather than a usage counter.

Since we have limited bits for struct nbcon_state, we need to stop
entering unsafe within nbcon_kdb_try_acquire(). As I mentioned in the
response to your cover letter, all the other CPUs should be quiesced
anyway.

John

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

[Petr Mladek]

On Fri 2026-09-25 15:14:16, John Ogness wrote:
> On 2026-09-22, Petr Mladek <pmladek@suse.com> wrote:
> > I have been working on v5 [1] of the patchset cleaning console registration
> > code and I found that the system did not boot when I selected a Braille
> > on the command line, for example:
> >
> >      console=brl,ttyS0,115200 console=tty0
> >
> > Bisection went down to the commit d3539347022a ("serial: 8250: Switch to
> > nbcon console, take 2"). I found that the Braille console driver called
> > braille_co->write() internally where braille_co pointed to the uart
> > 8250 driver.
> 
> The Braille console blindly calling (struct console).write() is
> obviously bad. This needs to be fixed. And not just because of the
> 8250. Other NBCON drivers already exist mainline and have this same
> issue.
> 
> > I added the support for the nbcon console API similar way as we did
> > for kdb [2].
> 
> kdb does not need to care about latencies. The Braille consoles do. I
> will comment more on this in the related patch.
> 
> > Note 1: I believe that we have a bug in the kdb patch because we call
> >         con->write() atomic callback after entering the unsafe mode.
> >         But we should do so in the default "safe" mode.
> 
> Why do you believe this? kdb operates within an unsafe section so that
> other CPUs cannot take ownership. (BTW: For kdb the other CPUs are
> supposed to be quiesced, so there should not be any ownership attempts
> anyway. The unsafe section is just an extra precaution.)

It is safe from the kdb context POV. But it is not right from the API
POV. The API does not suport nested unsafe section, so the following
happens:

  kdb_msg_write()

	nbcon_kdb_try_acquire(c, &wctxt);
	// on success: nbcon acquired, entered unsafe context
	c->write_atomic(c, &wctxt);

		serial8250_console_write()
			nbcon_enter_unsafe()
			// nested unsafe context
			nbcon_exit_unsafe(wctxt);
			// the nbcon context is marked as safe
			return;

	// the nbcon context is marked as save even though
	// kdb_msg_write() did not call nbcon_exit_unsafe()
	// which might lead to bugs

As you say, it is not a real problem here in the kdb code
because other CPUs are stopped. But it is an error prone pattern.
IMHO, we have already talked about adding warnings to catch nested
nbcon_enter_unsafe()/nbcon_exit_unsafe() calls.


> > Note 2: I am not completely sure about the locking. It might be better
> >         to use NBCON_PRIO_PANIC in panic().
> 
> Why does it matter? printk() is not trying to do any Braille printing
> during panic, so it will not attempt to acquire the Braille console.

The Braille console show exactly what the graphical console show.
It shows printk() messages when ttyX is registered as a console.

> >       Also I thought about using con->write_thread(). But I think
> > 	that we have to use the atomic variant because the Braille
> > 	console can be called from printk() via the VT code, aka
> > 	graphical console.
> 
> How can it be called from printk()? Even printk() writing to VT is only
> if it is registered as a console. Braille consoles are not registered.
> Please explain.

I have added WARN_ON() into braille_write() and got this:

[    0.069344] WARNING: drivers/accessibility/braille/braille_console.c:115 at braille_write+0x231/0x300, CPU#0: swapper/0/0
[    0.069352] Modules linked in:
[    0.069355] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5-default+ #139 PREEMPT(full)  db5f4527e6a3b5c4863452c3023f648284afb38d
[    0.069358] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-2-g4f253b9b-prebuilt.qemu.org 04/01/2014
[    0.069359] RIP: 0010:braille_write+0x231/0x300
[    0.069362] Code: 71 02 41 83 c8 40 44 88 06 48 8d 56 02 c6 46 01 02 41 f6 42 49 01 0f 84 98 00 00 00 49 83 ba 80 00 00 00 00 0f 84 b0 00 00 00 <0f> 0b 48 8d 74 24 5a 48 8d 7c 24 08 29 f2
 e8 2c d2 08 ff 48 8b 3d
[    0.069363] RSP: 0000:ffffffffaf603b78 EFLAGS: 00010086
[    0.069365] RAX: ffffffffb15c2e70 RBX: ffffffffb15c2e20 RCX: ffffffffaf603bfb
[    0.069366] RDX: ffffffffaf603bfe RSI: ffffffffaf603bfc RDI: 0000000000000020
[    0.069367] RBP: 00000000ffffffff R08: 0000000000000045 R09: ffffffffb15c2e70
[    0.069367] R10: ffffffffaf9f5a20 R11: 0000000000000000 R12: 0000000000000000
[    0.069368] R13: 0000000000000003 R14: ffffffffaf603ce8 R15: ffffffffafa33930
[    0.069371] FS:  0000000000000000(0000) GS:ffff8d04287a1000(0000) knlGS:0000000000000000
[    0.069372] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.069373] CR2: ffff8d03fffff000 CR3: 000000000b656000 CR4: 00000000000100b0
[    0.069376] Call Trace:
[    0.069377]  <TASK>
[    0.069378]  ? check_prev_add+0xf2/0xe40
[    0.069392]  ? lock_acquire.part.0+0xc5/0x230
[    0.069394]  ? atomic_notifier_call_chain+0x2a/0x110
[    0.069398]  vt_notifier_call+0x183/0x380
[    0.069402]  ? rcu_is_watching+0x11/0x50
[    0.069405]  ? __pfx_vt_notifier_call+0x10/0x10
[    0.069406]  notifier_call_chain+0x5d/0x170
[    0.069413]  atomic_notifier_call_chain+0x5f/0x110
[    0.069417]  vt_console_print+0x22e/0x4c0
[    0.069424]  ? console_emit_next_record+0x23a/0x2c0
[    0.069428]  console_emit_next_record+0x264/0x2c0
[    0.069430]  ? console_emit_next_record+0x23a/0x2c0
[    0.069439]  console_flush_one_record+0x210/0x340
[    0.069446]  console_unlock+0x6f/0x130
[    0.069447]  ? vprintk_emit+0x187/0x250
[    0.069451]  vprintk_emit+0x1fe/0x250
[    0.069457]  _printk+0x5b/0x80
[    0.069463]  ? __pfx_univ8250_console_init+0x10/0x10
[    0.069470]  lockdep_init+0x10/0xc0
[    0.069474]  start_kernel+0x5f2/0x720
[    0.069481]  x86_64_start_reservations+0x24/0x30
[    0.069484]  x86_64_start_kernel+0xd5/0xe0
[    0.069487]  common_startup_64+0x13e/0x151
[    0.069501]  </TASK>
[    0.069502] irq event stamp: 324
[    0.069502] hardirqs last  enabled at (323): [<ffffffffad43d623>] __down_trylock_console_sem+0x93/0xa0
[    0.069506] hardirqs last disabled at (324): [<ffffffffad44072e>] console_emit_next_record+0x21e/0x2c0
[    0.069507] softirqs last  enabled at (0): [<0000000000000000>] 0x0
[    0.069510] softirqs last disabled at (0): [<0000000000000000>] 0x0
[    0.069511] ---[ end trace 0000000000000000 ]---

This shows that braille_write() is called form printk() even when
braille_co is not in console_list. It is called via vt_console_print()
because the graphical console driver (ttyX) is registered.

Best Regards,
Petr

Re: [PATCH 2/2] braille: nbcon: Use nbcon atomic console callbacks

[John Ogness]

On 2026-09-22, Petr Mladek <pmladek@suse.com> wrote:
> The Braille console is integrated with the virtual terminal (VT) and
> writes its data using the legacy con->write() callback of the associated
> serial console driver.
>
> However, once the underlying console driver is converted to the NBCON
> API, it should use the con->write_atomic() callback, which must be
> synchronized by acquiring the nbcon console context.
>
> Adapt braille_write() to handle NBCON consoles:
>
> 1. Acquire the nbcon console ownership using NBCON_PRIO_EMERGENCY
>    priority before printing, disabling local interrupts to prevent
>    any nested calls into the driver.
> 2. Call the con->write_atomic() callback to write the buffer.
> 3. Release the nbcon console ownership and restore local interrupts.
>
> Also, adjust __serial8250_console_write() in the 8250 serial driver to
> exclude Braille consoles from the newline prepending logic. The serial
> port is not used for standard printk logging which might be interrupted
> in the middle of the operation. In the Braille mode, the serial driver
> is supposed to write exactly what it gets. In fact, it does not print
> any newlines at all in this case.
>
> Fixes: d3539347022a ("serial: 8250: Switch to nbcon console, take 2")
> Signed-off-by: Petr Mladek <pmladek@suse.com>
> ---
>  .../accessibility/braille/braille_console.c   | 38 ++++++++++++++++++-
>  drivers/tty/serial/8250/8250_port.c           |  5 ++-
>  2 files changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/accessibility/braille/braille_console.c b/drivers/accessibility/braille/braille_console.c
> index 06b43b678d6e..cd1019d478db 100644
> --- a/drivers/accessibility/braille/braille_console.c
> +++ b/drivers/accessibility/braille/braille_console.c
> @@ -62,14 +62,32 @@ static void braille_write(u16 *buf)
>  {
>  	static u16 lastwrite[WIDTH];
>  	unsigned char data[1 + 1 + 2*WIDTH + 2 + 1], csum = 0, *c;
> +	struct nbcon_write_context wctxt = { };
> +	unsigned long flags;
> +
>  	u16 out;
>  	int i;
>  
>  	if (!braille_co)
>  		return;
>  
> +	if (braille_co->flags & CON_NBCON) {
> +		/*
> +		 * Braille console might be called from unknown context via
> +		 * vt_console_print() from console_unlock() from printk().

printk()?

> +		 * Use the atomic callback and synchronize it just using
> +		 * the console context. Disable interrupts to prevent a nested
> +		 * call into the driver code which might cause a deadlock when
> +		 * trying to acquire the console ownership, see
> +		 * __nbcon_atomic_flush_pending_con().
> +		 */
> +		local_irq_save(flags);

This is not acceptable for PREEMPT_RT.

local_lock_irqsave() should be appropriate since this driver is not
called from printk(). ...if we want to take this route. More below...

> +		while (!nbcon_braille_try_acquire(braille_co, &wctxt))
> +			cpu_relax();
> +	}
> +
>  	if (!memcmp(lastwrite, buf, WIDTH * sizeof(*buf)))
> -		return;
> +		goto release_nbcon;
>  	memcpy(lastwrite, buf, WIDTH * sizeof(*buf));
>  
>  #define SOH 1
> @@ -102,7 +120,23 @@ static void braille_write(u16 *buf)
>  	*c++ = csum;
>  	*c++ = ETX;
>  
> -	braille_co->write(braille_co, data, c - data);
> +	if (braille_co->flags & CON_NBCON) {
> +		if (braille_co->write_atomic &&
> +		    !braille_co->flags & CON_NBCON_ATOMIC_UNSAFE) {
> +			nbcon_write_context_set_buf(&wctxt, (char *)data, c - data);
> +			braille_co->write_atomic(braille_co, &wctxt);
> +		} else {
> +			pr_warn_once("Braille requires a safe braille_co->write_atomic callback\n");
> +		}
> +	} else {
> +		braille_co->write(braille_co, data, c - data);
> +	}
> +
> +release_nbcon:
> +	if (braille_co->flags & CON_NBCON) {
> +		nbcon_braille_release(&wctxt);
> +		local_irq_restore(flags);
> +	}
>  }

If we want to "convert" the Braille console to NBCON, we need to have
established contexts so that we know what we can do. kdb was a horrible
hack that was only acceptable because when kdb is active, the whole
system goes out to lunch. But for the Braille console we need some
sanity because this is a live system.

AFAICT braille_write() is called from interrupt-handler and task
contexts. Can we buffer the writes and wake a dedicated kthread to
processes them using ->lock() and ->write_thread()? We can use spinlocks
to synchronize the FIFO buffer.

>  /* Follow the VC cursor*/
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 38fa45e74a37..6eb0b439e433 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -3417,8 +3417,11 @@ static void __serial8250_console_write(struct uart_8250_port *up,
>  	 * If the console printer did not fully output the previous line, it
>  	 * must have been handed or taken over. Insert a newline in order to
>  	 * maintain clean output.
> +	 *
> +	 * Braille consoles are an exception. The serial port is not used
> +	 * for printk(). The driver is supposed to write exactly what it gets.
>  	 */
> -	if (!up->console_line_ended) {
> +	if (unlikely(!up->console_line_ended && !nbcon_is_braille(wctxt))) {

Indeed. I am just wondering if it should be more generic.

nbcon_is_registered() ?
nbcon_supports_printk() ?

Or do we really want Braille to be the one and only exception.

Also note that this code exists in other NBCON drivers as well. At some
point we will need to create a general solution to adding \n on
takeovers.

John

Re: [PATCH 1/2] printk: nbcon: Introduce Braille helpers

[Petr Mladek]

On Fri 2026-09-25 15:54:52, John Ogness wrote:
> On 2026-09-22, Petr Mladek <pmladek@suse.com> wrote:
> > These helpers will be used when calling console->write_atomic
> > in the Braille console driver.
> >
> > The Braille console is not registered as a standard printk console.
> > Instead, it is integrated with the virtual terminal (VT) and writes
> > data using the legacy con->write() callback of the associated serial
> > console driver.
> >
> > When the underlying console driver is converted to the NBCON API, the
> > Braille console needs to use the con->write_atomic() callback instead.
> > This callback must be synchronized by acquiring the nbcon console context.
> >
> > Fixes: d3539347022a ("serial: 8250: Switch to nbcon console, take 2")
> 
> This is not 8250 specific. But I am not sure which commit you want to
> mark as Fixes.
> 
> For 62627bf0cadf ("kdb: Adapt kdb_msg_write to work with NBCON
> consoles") there was no Fixes tag.

You are right. I somehow though that it was connected with the uart
8250 serial console. But the code allows to use it with other console
drivers as well.

Well, I guess that the driver was created for a particular Braille
device. I wonder if there exists Braille devices working with
other serial ports which are compatible...

I could omit the Fixes tag. But I think that in practice it is
primary for the uart 8250 driver.

> > Signed-off-by: Petr Mladek <pmladek@suse.com>
> > ---
> >  include/linux/console.h |  8 ++++++
> >  kernel/printk/nbcon.c   | 59 +++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 67 insertions(+)
> >
> > diff --git a/include/linux/console.h b/include/linux/console.h
> > index 502d1abe3f50..d780f6de303a 100644
> > --- a/include/linux/console.h
> > +++ b/include/linux/console.h
> > @@ -615,6 +615,10 @@ extern bool nbcon_allow_unsafe_takeover(void);
> >  extern bool nbcon_kdb_try_acquire(struct console *con,
> >  				  struct nbcon_write_context *wctxt);
> >  extern void nbcon_kdb_release(struct nbcon_write_context *wctxt);
> > +extern bool nbcon_is_braille(struct nbcon_write_context *wctxt);
> > +extern bool nbcon_braille_try_acquire(struct console *con,
> > +				      struct nbcon_write_context *wctxt);
> > +extern void nbcon_braille_release(struct nbcon_write_context *wctxt);
> >  
> >  /*
> >   * Check if the given console is currently capable and allowed to print
> > @@ -678,8 +682,12 @@ static inline void nbcon_reacquire_nobuf(struct nbcon_write_context *wctxt) { }
> >  static inline bool nbcon_kdb_try_acquire(struct console *con,
> >  					 struct nbcon_write_context *wctxt) { return false; }
> >  static inline void nbcon_kdb_release(struct nbcon_write_context *wctxt) { }
> > +static inline bool nbcon_is_braille(struct nbcon_write_context *wctxt) { return false; }
> >  static inline bool console_is_usable(struct console *con, short flags,
> >  				     bool use_atomic) { return false; }
> > +static inline bool nbcon_braille_try_acquire(struct console *con,
> > +					     struct nbcon_write_context *wctxt) { return false; }
> > +static inline void nbcon_braille_release(struct nbcon_write_context *wctxt) { }
> >  #endif
> >  
> >  extern int console_set_on_cmdline;
> > diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> > index d17704fe93ae..a5e053ffe4da 100644
> > --- a/kernel/printk/nbcon.c
> > +++ b/kernel/printk/nbcon.c
> > @@ -2002,3 +2002,62 @@ void nbcon_kdb_release(struct nbcon_write_context *wctxt)
> >  	 */
> >  	__nbcon_atomic_flush_pending_con(ctxt->console, prb_next_reserve_seq(prb));
> >  }
> > +
> > +/**
> > + * nbcon_is_braille - Checks whether the nbcon write context is using Braille console
> > + *
> > + * @wctxt:	checked nbcon write context
> > + *
> > + * Return: True when the write context is associated with a Braille console.
> > + *	   Othrewise, return false.
> > + *
> > + * Context: Can be called in any context but only when Braille console is
> > + *	registered and the struct console could not disappear.
> > + */
> > +bool nbcon_is_braille(struct nbcon_write_context *wctxt)
> > +{
> > +	struct nbcon_context *ctxt = &ACCESS_PRIVATE(wctxt, ctxt);
> > +	struct console *con = ctxt->console;
> > +
> > +	return con && con->flags & CON_BRL;
> > +}
> > +
> > +/**
> > + * nbcon_braille_try_acquire - Try to acquire nbcon console for braille_write()
> > + *
> > + * @con:	The nbcon console to acquire
> > + * @wctxt:	The nbcon write context to be used on success
> > + *
> > + * Context:	braille_write() for emitting a single buffer on Braille console.
> > + *
> > + * Return:	True if the console was acquired. False otherwise.
> > + *
> > + * Braille console is not registered as a proper printk consoles. Instead,
> > + * it is integrated with the graphical virtual terminal.
> > + *
> > + * This function acquires the nbcon console using priority NBCON_PRIO_EMERGENCY.
> > + */
> > +bool nbcon_braille_try_acquire(struct console *con,
> > +			   struct nbcon_write_context *wctxt)
> > +{
> > +	struct nbcon_context *ctxt = &ACCESS_PRIVATE(wctxt, ctxt);
> > +
> > +	memset(ctxt, 0, sizeof(*ctxt));
> > +	ctxt->console = con;
> > +	ctxt->prio    = NBCON_PRIO_EMERGENCY;
> > +
> > +	return nbcon_context_try_acquire(ctxt, false);
> > +}
> 
> This is really the same thing as nbcon_kdb_try_acquire().
> 
> As you mentioned in your cover letter, it is a bug that
> nbcon_kdb_try_acquire() enters an unsafe section because @unsafe is a
> bool rather than a usage counter.
> 
> Since we have limited bits for struct nbcon_state, we need to stop
> entering unsafe within nbcon_kdb_try_acquire(). As I mentioned in the
> response to your cover letter, all the other CPUs should be quiesced
> anyway.

I working on v2 today morning and looked at it from different angles.
I decided to send v2 where I described my thoughts, see
https://lore.kernel.org/all/20260925141729.173943-1-pmladek@suse.com/

I guess that we need another solution at least for PREEMPT_RT.
But I am not sure how to do so correctly.

Sigh, the Braille console is quite a hack. I am afraid that the NBCON
API is not ready for this use case. IMHO, the most similar user
is nbcon_legacy_emit_next_record() which is used to flush nbcon
consoles from the legacy loop when some early console driver is
still registered.

Best Regards,
Petr

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

[John Ogness]

On 2026-09-25, Petr Mladek <pmladek@suse.com> wrote:
> This shows that braille_write() is called form printk() even when
> braille_co is not in console_list. It is called via vt_console_print()
> because the graphical console driver (ttyX) is registered.

But isn't that a bug? I thought Braille consoles were not supposed to be
handled by printk(). Even in this new series you added that exact
comment.

John

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

[Petr Mladek]

On Fri 2026-09-25 16:42:19, John Ogness wrote:
> On 2026-09-25, Petr Mladek <pmladek@suse.com> wrote:
> > This shows that braille_write() is called form printk() even when
> > braille_co is not in console_list. It is called via vt_console_print()
> > because the graphical console driver (ttyX) is registered.
> 
> But isn't that a bug? I thought Braille consoles were not supposed to be
> handled by printk(). Even in this new series you added that exact
> comment.

I believe that it is not a bug. I understand it the way that the
Braille device should show everything that is shown on the virtual
terminal. It should show the printk() messages when they are
printed there by the related console driver.

It is just that printk() is only one source of messages shown
on the terminal. The vt code maintains what is displayed.

Best Regards,
Petr

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

[John Ogness]

On 2026-09-25, Petr Mladek <pmladek@suse.com> wrote:
>> > This shows that braille_write() is called form printk() even when
>> > braille_co is not in console_list. It is called via vt_console_print()
>> > because the graphical console driver (ttyX) is registered.
>> 
>> But isn't that a bug? I thought Braille consoles were not supposed to be
>> handled by printk(). Even in this new series you added that exact
>> comment.
>
> I believe that it is not a bug. I understand it the way that the
> Braille device should show everything that is shown on the virtual
> terminal. It should show the printk() messages when they are
> printed there by the related console driver.
>
> It is just that printk() is only one source of messages shown
> on the terminal. The vt code maintains what is displayed.

But how do you register "the terminal" so that printk messages appear
there?

John

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

[Petr Mladek]

On Fri 2026-09-25 17:11:44, John Ogness wrote:
> On 2026-09-25, Petr Mladek <pmladek@suse.com> wrote:
> >> > This shows that braille_write() is called form printk() even when
> >> > braille_co is not in console_list. It is called via vt_console_print()
> >> > because the graphical console driver (ttyX) is registered.
> >> 
> >> But isn't that a bug? I thought Braille consoles were not supposed to be
> >> handled by printk(). Even in this new series you added that exact
> >> comment.
> >
> > I believe that it is not a bug. I understand it the way that the
> > Braille device should show everything that is shown on the virtual
> > terminal. It should show the printk() messages when they are
> > printed there by the related console driver.
> >
> > It is just that printk() is only one source of messages shown
> > on the terminal. The vt code maintains what is displayed.
> 
> But how do you register "the terminal" so that printk messages appear
> there?

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.

Best Regards,
Petr

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

[John Ogness]

On 2026-09-25, Petr Mladek <pmladek@suse.com> 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().

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();

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.

John