mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>,
	Chris Down <chris@chrisdown.name>,
	linux-kernel@vger.kernel.org, Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH v2 3/9] printk: Separate code for adding/updating preferred console metadata
Date: Fri, 15 May 2026 12:29:14 +0206	[thread overview]
Message-ID: <87o6ih6kfh.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20260423130015.85175-4-pmladek@suse.com>

On 2026-04-23, Petr Mladek <pmladek@suse.com> wrote:
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 13c98285892b..d251bf8e104f 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2544,18 +2544,119 @@ asmlinkage __visible void early_printk(const char *fmt, ...)
>  }
>  #endif
>  
> -static void set_user_specified(struct preferred_console *pc, bool user_specified)
> +/** update_preferred_console - Update a given entry in the preferred_consoles[]
> + *	table.

Perhaps the description should be:

Update or add a given entry in the preferred_consoles[] table.

If the caller didn't match an existing preferred_console, this function
is called to add a new entry. This is obvious if you are looking at the
caller, but it is not obvious at all if you are only looking at this
function, i.e. strscpy'ing in @name or @devname is the only clue that
you are dealing with a new entry.

> + * @i: index of the entry in @preferred_consoles table which should get updated.
> + * @name: The name of the preferred console driver.
> + * @idx: Preferred console index, e.g. port number.
> + * @devname: The name of the preferred physical device.
> + * @options: Options used when setting up the console driver.
> + * @brl_options: Options used when setting up the console driver
> + *	as a braille console.
> + * @user_specified: True if preferred via the kernel command line.
> + *
> + * The function ensures that the given values are consistent. Also
> + * it updates some global variables which are used to make the right
> + * decisions in register_console().
> + *
> + * Rules:
> + *
> + *   1. Either @name and valid @idx OR @devname and @idx=-1 are allowed.
> + *	Note that a valid @name and @idx will get assigned later when
> + *	@devname matches during the device initialization.
> + *   2. Specify @brl_options if the console should be enabled as
> + *	a Braille console [*]
> + *   3. Only matching entries can be updated.
> + *   4. @options passed via the command line are used when the same
> + *	console is preferred also by some platform-specific code.
> + *
> + * [*] Braille console is using the mechanism for registering consoles
> + *     but it is very special. It is primarily used for user interaction
> + *     with the system. It neither gets printk() messages nor is associated
> + *     with /dev/console.
> + */
> +static int update_preferred_console(unsigned int i,
> +				    const char *name, const short idx,
> +				    const char *devname, char *options,
> +				    char *brl_options, bool user_specified)
>  {
> -	if (!user_specified)
> -		return;
> +	struct preferred_console *pc;
> +
> +	if (i >= MAX_PREFERRED_CONSOLES)
> +		return -E2BIG;
> +
> +	pc = &preferred_consoles[i];
> +
> +	if (!name && !devname)
> +		return -EINVAL;

You are adding detailed error messages for all possible wrong calls
except for this on. Maybe this should be covered as well with:

	if (WARN_ON(!name && !devname))
		return -EINVAL;

> +	if (devname) {
> +		/*
> +		 * A valid console name and index will get assigned when
> +		 * a matching device gets registered.
> +		 */
> +		if (name) {
> +			pr_err("Adding a preferred console devname with a hard-coded console name: %s, %s\n",
> +			       devname, name);
> +			return -EINVAL;
> +		}
> +		if (pc->name[0]) {
> +			pr_err("Updating a preferred console entry with an already assigned console name via devname: %s, %s\n",
> +			       devname, pc->name);
> +			return -EINVAL;
> +		}
> +		if (idx != -1) {
> +			pr_err("Adding a preferred console devname with a hard-coded index: %s, %d\n",
> +			       devname, idx);
> +			return -EINVAL;
> +		}
> +
> +		if (!pc->devname[0]) {
> +			strscpy(pc->devname, devname);
> +			pc->index = idx;

This block is about setting the devname. Setting the index here as well
is copied code and well hidden. I would keep the index setting outside
the devname and name blocks (as it was previously).

> +		} else if (strcmp(pc->devname, devname) != 0) {
> +			pr_err("Updating a preferred console with an invalid devname: %s vs. %s\n",
> +			       pc->devname, devname);
> +			return -EINVAL;
> +		}
> +	}
> +
> +	if (name) {
> +		/* A console name must be defined with a valid index. */
> +		if (idx < 0) {
> +			pr_err("Adding a preferred console with an invalid index: %s, %d\n",
> +			       name, idx);
> +			return -EINVAL;
> +		}
> +
> +		if (!pc->name[0]) {
> +			strscpy(pc->name, name);
> +			pc->index = idx;

Here is the copied code. This block is about setting the name.

> +		} else if (strcmp(pc->name, name) != 0 || pc->index != idx) {
> +			pr_err("Updating a preferred console with an invalid name or index: %s%d vs. %s%d\n",
> +			       pc->name, pc->index, name, idx);
> +			return -EINVAL;
> +		}
> +	}

I would put the index setting here as it is relevant regardless of how
the devname or name was updated.

	pc->index = idx;

With or without implementing my suggestions:

Reviewed-by: John Ogness <john.ogness@linutronix.de>

  parent reply	other threads:[~2026-05-15 10:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-23 13:00 [PATCH v2 0/9] printk: Clean up preferred console handling Petr Mladek
2026-04-23 13:00 ` [PATCH v2 1/9] printk: Rename struct console_cmdline to preferred_console Petr Mladek
2026-04-23 14:16   ` Steven Rostedt
2026-05-08 14:22   ` John Ogness
2026-04-23 13:00 ` [PATCH v2 2/9] printk: Rename preferred_console to preferred_dev_console Petr Mladek
2026-05-15  9:07   ` John Ogness
2026-04-23 13:00 ` [PATCH v2 3/9] printk: Separate code for adding/updating preferred console metadata Petr Mladek
2026-05-05 17:47   ` Marcos Paulo de Souza
2026-05-15 10:23   ` John Ogness [this message]
2026-05-15 10:30     ` John Ogness
2026-05-29 10:06       ` Petr Mladek
2026-05-29 10:05     ` Petr Mladek
2026-04-23 13:00 ` [PATCH v2 4/9] printk: Cleanup _braille_(un)register_console() wrappers Petr Mladek
2026-05-15 12:51   ` John Ogness
2026-04-23 13:00 ` [PATCH v2 5/9] printk: Separate code for enabling console Petr Mladek
2026-05-05 17:56   ` Marcos Paulo de Souza
2026-05-15 12:57   ` John Ogness
2026-04-23 13:00 ` [PATCH v2 6/9] printk: Try to register each console as Braille first Petr Mladek
2026-04-23 13:00 ` [PATCH v2 7/9] printk: Do not set Braille console as preferred_console Petr Mladek
2026-04-23 13:00 ` [PATCH v2 8/9] printk: Handle pre-enabled consoles in the top-level try_enable_console() Petr Mladek
2026-04-23 13:00 ` [PATCH v2 9/9] printk: Try enable preferred consoles only when there are any Petr Mladek
2026-05-29 15:22   ` Petr Mladek
2026-04-24  8:20 ` [PATCH v2 0/9] printk: Clean up preferred console handling 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=87o6ih6kfh.fsf@jogness.linutronix.de \
    --to=john.ogness@linutronix.de \
    --cc=chris@chrisdown.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpdesouza@suse.com \
    --cc=pmladek@suse.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 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®