From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
Marcos Paulo de Souza <mpdesouza@suse.com>,
Chris Down <chris@chrisdown.name>,
Naveen Kumar Chaudhary <naveen.osdev@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 13/16] printk: Try to register each console as Braille first
Date: Fri, 6 Nov 2026 12:33:56 +0100 [thread overview]
Message-ID: <au27JKkPAnhj26jI@pathway.suse.cz> (raw)
In-Reply-To: <20260929120546.328616-14-pmladek@suse.com>
On Tue 2026-09-29 14:05:43, Petr Mladek wrote:
> Braille consoles are unique: they can only be enabled via the command
> line and use the preferred console framework for initialization, yet
> they are never added to the console_list or associated with
> /dev/console. Because of this, the preferred_console variable remains
> unset when only a Braille console is requested.
>
> Currently, try_enable_preferred_console() must be called even when
> "preferred_dev_console" variable is not set, just to catch these "hidden"
> Braille requests.
>
> Refactor the logic by adding a parameter to try_enable_preferred_console()
> to explicitly handle Braille vs. non-Braille cases. It will eventually
> allow to skip try_enable_preferred_console() when there are no preferred
> consoles. This improves code robustness by ensuring the console
> setup is explicit and only performed once.
>
> Note that _braille_register_console() is skipped when the given console
> driver has a match() callback and it succeeded. It means that it took
> over an early console and can't be used as a Braille console.
>
> As a result try_enable_braille_console() might return success even
> when it did not enabled the console in the Braille mode. It is
> the reason why register_console() has to explicitly check whether
> CON_BRL flag was really set and could skip the further steps.
>
> The refactoring even fixes two subtle bugs:
>
> 1. When only the Braille console is defined on the command line,
> the original code might attempt to enable the same console twice—once
> as a default and once as a Braille console. This results in calling
> the setup() callback twice and incorrectly setting the CON_CONSDEV flag.
>
> 2. When the same console is defined on the command line using devname
> and then as Braille console, for example:
>
> console=00:00:0.0,115200 console=brl,ttyS0,115200
>
> It would have two separate entries in preferred_consoles[] array.
>
> The 2nd (Braille) entry would be used when univ8250_console_init()
> tries to register the generic "ttyS" console driver. Note that
> the 1st entry still does not have defined the "name" entry at
> this stage.
>
> The 1st non-Braille entry would be used later when serial8250_init()
> registers all found devices, assigns "tty0" for the given "00:00:0.0"
> devname and tries to register the same struct console once again.
>
> The original code would call newcon->setup() twice in this scenario.
> It won't add the console into console_list only because the later
> check in register_console() would detect CON_BRL flag set from
> the 1st registration and return early.
>
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3995,7 +4012,7 @@ static int try_enable_preferred_console(struct console *newcon,
> if (newcon->index < 0)
> newcon->index = pc->index;
>
> - if (is_braille_console_preferred(pc))
> + if (try_only_braille)
> return _braille_register_console(newcon, pc);
>
> err = console_call_setup(newcon, pc->options);
From Sashiko AI:
| Does returning 0 here for a Braille match cause the console to lose its
| preferred status?
|
| When newcon->match() succeeds, the loop falls through to:
|
| newcon->flags |= CON_ENABLED;
| if (i == preferred_dev_console)
| newcon->flags |= CON_CONSDEV;
| return 0;
|
| When returning 0 here after a successful newcon->match() during the
| try_only_braille phase, CON_CONSDEV is not set because preferred_dev_console
| is never assigned to a Braille entry.
This works as expected. The CON_CONSDEV flag is set here only when
the related preferred_consoles[i] entry was the latest added/updated
entry for a non-Braille console.
Note that there are more situations when the `preferred_dev_console`
is not registered, for example, when there is a typo, or when
the related HW is not available.
For this situation, the CON_CONSDEV flag is always assigned to the
1st registered console driver, see the commit 33225d7b0ac990
("printk: Correctly set CON_CONSDEV even when preferred console
was not registered").
[ ... ]
> @@ -4033,6 +4061,24 @@ static int try_enable_console(struct console *newcon)
> {
> int err;
>
> + /*
> + * First, try to enable the console driver as a Braille console.
> + * It would have metadata in the preferred_consoles[] array.
> + * But it won't be counted as @preferred_console because
> + * it does not get printk() messages and is not associated
> + * with /dev/console.
> + *
> + * Note that it might succeed also when the driver has a match()
> + * callback and it took over a boot console. In this case,
> + * the driver will continue working as a classic non-Braille
> + * console.
> + */
> + if (want_braille_console) {
> + err = try_enable_braille_console(newcon);
> + if (err != -ENOENT)
> + return err;
> + }
Sashiko AI wrote:
| If the user specified both a regular console and a Braille console
| (e.g. console=ttyS0 console=brl,uart,...), does this early return preempt
| the regular console entry from being evaluated?
|
| If a driver matches the Braille entry and returns 0 without setting
| CON_CONSDEV, returning early here means the regular preferred console entries
| are skipped. This seems to break /dev/console routing, as the expected
| primary console never receives CON_CONSDEV.
The problem with CON_CONSDEV is basically the same as above.
But there is another interesting question whether the console driver
can be used as a classic printk console even it could not get enabled
as a Braille console. I mean whether, for example,
try_enable_default_console(newcon) would fail when
try_enable_braille_console(newcon) failed.
I could imagine that the driver might be usable and only the
VT integration failed. But the VT integration never fails,
see braille_register_console().
Also I think that we do not want to use this driver as a normal
console when it was configured to be used by the Braille console.
Best Regards,
Petr
next prev parent reply other threads:[~2026-11-06 11:34 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 12:05 [PATCH v5 00/16] printk: Clean up preferred console handling Petr Mladek
2026-09-29 12:05 ` [PATCH v5 01/16] printk: Rename struct console_cmdline to preferred_console Petr Mladek
2026-10-29 7:03 ` Chris Down
2026-11-03 15:16 ` Petr Mladek
2026-09-29 12:05 ` [PATCH v5 02/16] printk: Rename preferred_console to preferred_dev_console Petr Mladek
2026-09-29 12:05 ` [PATCH v5 03/16] printk: Cleanup _braille_(un)register_console() wrappers Petr Mladek
2026-09-29 12:05 ` [PATCH v5 04/16] printk: Separate code for adding/updating preferred console metadata Petr Mladek
2026-10-27 12:05 ` John Ogness
2026-11-03 15:57 ` Petr Mladek
2026-10-29 7:05 ` Chris Down
2026-11-03 16:12 ` Petr Mladek
2026-09-29 12:05 ` [PATCH v5 05/16] printk: Prefer the console either via name or devname exclusively Petr Mladek
2026-10-27 12:14 ` John Ogness
2026-10-29 7:06 ` Chris Down
2026-09-29 12:05 ` [PATCH v5 06/16] printk: Check that index is not defined when a console is preferred via devname Petr Mladek
2026-10-27 18:08 ` John Ogness
2026-10-29 7:07 ` Chris Down
2026-09-29 12:05 ` [PATCH v5 07/16] printk: Ensure consistent name and devname when updating preferred console Petr Mladek
2026-10-29 7:09 ` Chris Down
2026-11-03 17:08 ` Petr Mladek
2026-09-29 12:05 ` [PATCH v5 08/16] printk: Do not quietly ignore adding entry for a preferred console when there is no space Petr Mladek
2026-10-29 7:10 ` Chris Down
2026-10-29 16:23 ` John Ogness
2026-09-29 12:05 ` [PATCH v5 09/16] printk: Allow to override options via the command line Petr Mladek
2026-10-29 7:13 ` Chris Down
2026-10-30 17:04 ` John Ogness
2026-11-04 12:55 ` Petr Mladek
2026-09-29 12:05 ` [PATCH v5 10/16] printk: Allow to debug misuse of add_or_update_preferred_console() Petr Mladek
2026-10-29 7:13 ` Chris Down
2026-09-29 12:05 ` [PATCH v5 11/16] console/braille: Lock console->setup() call during the registration Petr Mladek
2026-10-29 7:15 ` Chris Down
2026-11-04 14:21 ` Petr Mladek
2026-09-29 12:05 ` [PATCH v5 12/16] printk: Separate code for enabling console Petr Mladek
2026-10-29 7:15 ` Chris Down
2026-09-29 12:05 ` [PATCH v5 13/16] printk: Try to register each console as Braille first Petr Mladek
2026-10-29 7:17 ` Chris Down
2026-11-05 17:13 ` Petr Mladek
2026-11-06 11:33 ` Petr Mladek [this message]
2026-09-29 12:05 ` [PATCH v5 14/16] printk: Do not set Braille console as preferred_console Petr Mladek
2026-10-29 7:19 ` Chris Down
2026-11-06 14:21 ` Petr Mladek
2026-09-29 12:05 ` [PATCH v5 15/16] printk: Modify try_enable_default_console() to return error/success Petr Mladek
2026-10-29 7:20 ` Chris Down
2026-09-29 12:05 ` [PATCH v5 16/16] printk: Try enable preferred consoles only when there are any Petr Mladek
2026-10-29 7:20 ` Chris Down
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=au27JKkPAnhj26jI@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=chris@chrisdown.name \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mpdesouza@suse.com \
--cc=naveen.osdev@gmail.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.