From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>
Cc: "Sergey Senozhatsky" <senozhatsky@chromium.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Marcos Paulo de Souza" <mpdesouza@suse.com>,
"Samuel Thibault" <samuel.thibault@ens-lyon.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Hugo Villeneuve" <hvilleneuve@dimonoff.com>,
"Fushuai Wang" <wangfushuai@baidu.com>,
"Kees Cook" <kees@kernel.org>,
"Stepan Ionichev" <sozdayvek@gmail.com>,
linux-serial@vger.kernel.org,
"Manuel Lauss" <manuel.lauss@gmail.com>,
linux-kernel@vger.kernel.org, "Petr Mladek" <pmladek@suse.com>
Subject: Re: [PATCH 0/2] braille: nbcon: Allow using a serial driver converted to nbcon API as a Braille console
Date: Fri, 25 Sep 2026 15:14:16 +0206 [thread overview]
Message-ID: <87ik3tiim7.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20260922072558.98854-1-pmladek@suse.com>
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
next prev parent reply other threads:[~2026-09-25 13:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 7:25 Petr Mladek
2026-09-22 7:25 ` [PATCH 1/2] printk: nbcon: Introduce Braille helpers Petr Mladek
2026-09-25 13:48 ` John Ogness
2026-09-25 14:34 ` Petr Mladek
2026-09-22 7:25 ` [PATCH 2/2] braille: nbcon: Use nbcon atomic console callbacks Petr Mladek
[not found] ` <20260922073728.2ADCD1F000FF@smtp.kernel.org>
2026-09-23 14:39 ` Petr Mladek
2026-09-25 14:34 ` John Ogness
2026-09-24 23:53 ` [PATCH 0/2] braille: nbcon: Allow using a serial driver converted to nbcon API as a Braille console Samuel Thibault
2026-09-25 13:08 ` John Ogness [this message]
2026-09-25 14:10 ` Petr Mladek
2026-09-25 14:36 ` John Ogness
2026-09-25 14:49 ` Petr Mladek
2026-09-25 15:05 ` John Ogness
2026-09-25 15:41 ` Petr Mladek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ik3tiim7.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=hvilleneuve@dimonoff.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jirislaby@kernel.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=manuel.lauss@gmail.com \
--cc=mpdesouza@suse.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=samuel.thibault@ens-lyon.org \
--cc=senozhatsky@chromium.org \
--cc=sozdayvek@gmail.com \
--cc=wangfushuai@baidu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®