public inbox for driver-core@lists.linux.dev
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	Russ Weight <russ.weight@linux.dev>,
	Danilo Krummrich <dakr@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Michal Grzedzicki <mge@meta.com>,
	driver-core@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] firmware_loader: allow firmware_class.path to take multiple paths
Date: Thu, 19 Mar 2026 07:23:45 +0100	[thread overview]
Message-ID: <2026031940-baritone-handsaw-f1d3@gregkh> (raw)
In-Reply-To: <20260318-fw-path-v3-1-a701a08bc025@kernel.org>

On Wed, Mar 18, 2026 at 03:54:02PM -0400, Jeff Layton wrote:
> Refactor fw_get_filesystem_firmware() by extracting the per-path
> firmware loading logic into a new fw_try_firmware_path() helper.
> 
> Use this helper to parse fw_path_para for ':'-separated paths,
> trying each one before falling through to the default firmware
> search paths. This allows users to specify multiple custom firmware
> directories via firmware_class.path, e.g.:
> 
>   firmware_class.path=/custom/path1:/custom/path2
> 
> A backslash can be used as an escape character, allowing a literal
> ':' ("\:") or literal '\' ("\\") to be embedded in a pathname.

This is a mess, what could go wrong embedding another parser in the
kernel :)

Let's step back, why is this needed at all?  The kernel already supports
multiple standard locations for firmware paths, and one custom location.
Why do we now need more than that?  What changed to require this and who
is going to use it (and support it, and actually test it?)

We really want to make the number of firmware paths less, not more.  But
if we _really_ need multiple paths, isn't it simpler to just have an
array of paths here, not be forced to parse escape codes like you are
now doing?

thanks,

greg k-h

  reply	other threads:[~2026-03-19  6:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-18 19:54 [PATCH v3] firmware_loader: allow firmware_class.path to take multiple paths Jeff Layton
2026-03-19  6:23 ` Greg Kroah-Hartman [this message]
2026-03-19 11:34   ` Jeff Layton
2026-03-19 11:39     ` Greg Kroah-Hartman
2026-03-19 11:47       ` Jeff Layton
2026-03-19 12:04         ` Greg Kroah-Hartman
2026-03-19 14:13         ` Michal Grzedzicki
2026-03-19 15:30           ` Greg Kroah-Hartman
2026-03-19 15:51             ` Jeff Layton

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=2026031940-baritone-handsaw-f1d3@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=dakr@kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=jlayton@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mge@meta.com \
    --cc=rafael@kernel.org \
    --cc=russ.weight@linux.dev \
    /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