Re: [PATCH v3] firmware_loader: allow firmware_class.path to take multiple paths

[Greg Kroah-Hartman]

On Thu, Mar 19, 2026 at 07:34:46AM -0400, Jeff Layton wrote:
> On Thu, 2026-03-19 at 07:23 +0100, Greg Kroah-Hartman wrote:
> > 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 have at least one internal user that requested the ability to do
> this. I'll see if they can articulate their use-case better.

Please do.

> > 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?
> > 
> 
> How would one feed an array of paths to the module without delimiting
> them in some fashion?

I don't know, but once you start attempting to "escape" things, the
complexity goes up a lot and makes me think that this all isn't a good
idea :)

thanks,

greg k-h