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

[Michal Grzedzicki]

> On 19 Mar 2026, at 11:47, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> 
> On Thu, 2026-03-19 at 12:39 +0100, Greg Kroah-Hartman wrote:
>> 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.
>> 
> 
> Michal said he'll outline his use-case.


Internally, we distribute firmware binaries as read-only snapshots, and a system may have more than one. Without this feature, we must maintain a symlink farm to merge multiple snapshots into a single path. We would love to remove this workaround and switch to just passing multiple paths.

Also a common pattern I seen in vendor shell scripts is temporarily setting firmware_class.path to the current working directory, loading the module, and then restoring firmware_class.path to its previous value, with this feature it could be made safer.

Thanks,
Michal Grzedzicki