Received-SPF: pass (google.com: domain of linux-wireless+bounces-6453-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <b7876373-08d9-4948-a49a-e79f42f3abcb@gmail.com>
Date: Wed, 17 Apr 2024 08:58:19 -0500
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: putting future iwlwifi firmware into intel/ ?
Content-Language: en-US
To: Johannes Berg <johannes@sipsolutions.net>, linux-firmware@kernel.org
Cc: linux-wireless@vger.kernel.org, miriam.rachel.korenblit@intel.com
References: <fec30176f437d565d4c1dfc4944373f117d75a64.camel@sipsolutions.net>
 <9aa64d50-cb4d-4118-bc27-86c23410ff8b@gmail.com>
 <f65765b29ea7503fbbaa5e047c95a82de6fc2083.camel@sipsolutions.net>
 <b0e70576-a53f-4d03-a503-ddf1f98bbe9d@gmail.com>
 <b712f48a3e35221b7ff7f4c8cb495b5159bdd367.camel@sipsolutions.net>
From: Mario Limonciello <superm1@gmail.com>
In-Reply-To: <b712f48a3e35221b7ff7f4c8cb495b5159bdd367.camel@sipsolutions.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 4/17/24 07:45, Johannes Berg wrote:
> On Wed, 2024-04-17 at 07:42 -0500, Mario Limonciello wrote:
>>
>> On 4/17/24 07:39, Johannes Berg wrote:
>>> On Wed, 2024-04-17 at 07:31 -0500, Mario Limonciello wrote:
>>>>
>>>> On 4/17/24 06:18, Johannes Berg wrote:
>>>>> Hi,
>>>>>
>>>>> Since I was just looking at some firmware related thing (files for the
>>>>> hardware that might be shared between Intel BT and WiFi), I noticed that
>>>>> just over 30% of the files/dirs in the top-level firmware tree are
>>>>> iwlwifi-* files.
>>>>>
>>>>> While we can't move the files that older drivers might consume, we could
>>>>> e.g. change the driver to look up future versions/future hardware under
>>>>> intel/ instead? Would that be worth doing?
>>>>>
>>>>> johannes
>>>>>
>>>>
>>>> How about moving them all now and then creating compat symlinks for
>>>> older kernels at linux-firmware 'make install' time?
>>>>
>>>
>>> Didn't realize there even was a 'make install' time :-)
>>>
>>> But then I guess it'd be simpler in the driver since we could just
>>> unconditionally add the intel/ prefix to the request_firmware call.
>>>
>>> johannes
>>
>> Do both.  All the stuff already there add the compat symlinks in linux
>> firmware so that current and older kernels work with older hardware.
>>
>> Any "new firmware" only put in the new path, and add commits to the
>> kernel to look for "all" firmware in the new path.
>>
>> Should hopefully cover everything without too much pain then.
> 
> Yeah, I guess. Though not actually sure, do we need to support new
> kernel + old firmware install?
> 
> johannes

I'd say you should.  Here's a few examples of why:

1) Kernel documentation says so.  See 
https://github.com/torvalds/linux/blob/master/Documentation/driver-api/firmware/firmware-usage-guidelines.rst


2) Let's say you change this in latest linux-firmware and kernel 6.10 
but don't do a symlink.  A user upgrades to 6.10 and latest 
linux-firmware but finds a regression.  They're asked to come bisect it, 
but their kernel 6.9 can no longer work with wifi due to "missing" 
firmware.  The bisect gets WAY more painful.

3) Some distros do "HWE" kernels (for example Ubuntu).  This means they 
could do a HWE-6.10 or HWE-6.11 but expect that the exact same 
linux-firmware package works on all of them.  They could uprev their 
linux-firmware to the one matching this change but then their "LTS" 
kernel stops working.

So yes; do the symlinks when you move directories.  It's one line in 
WHENCE per file that you want a symlink.