Received-SPF: pass (google.com: domain of linux-wireless+bounces-6447-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <b0e70576-a53f-4d03-a503-ddf1f98bbe9d@gmail.com>
Date: Wed, 17 Apr 2024 07:42:30 -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>
From: Mario Limonciello <superm1@gmail.com>
In-Reply-To: <f65765b29ea7503fbbaa5e047c95a82de6fc2083.camel@sipsolutions.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


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.