Intel AC 9260 was launched Q4 2017 and it is still being sold (as far as I can see). I can understand not wanting it in the main package, but I would argue to not delete it, but rather moving it to a separate subpackage, e.g. "linux-firmware-old".
Downloading the old version of the package is easy for you and for me. But it can be challenging for a junior administrator.

This doesn't delete the current version of any firmware (intentionally).

The firmware naming convention is like this:

iwlwifi-(chipset)-(firmwareAPIversion).ucode

What this PR does is delete some older firmware API version files. For every chipset, at least the most recent firmware API version file remains; often I kept several older ones too.

The way the iwlwifi driver actually loads firmware, AIUI, is this. For each chipset, there's a minimum and maximum API version that the driver supports, defined in the source. It will first try and load the firmware file for the maximum API version it supports; if that file isn't there, it will subtract one from the version number and try again. It'll keep doing that until it hits a file that exists, and then it'll use that.

So for whatever kernel you're booting, you only need the highest versioned firmware file it supports for whatever chipset you're using. Older ones are useless and unnecessary. The reason to keep older ones around is in case you want to boot an older kernel whose maximum supported version is lower than a recent kernel, but I think we can make reasonable cutoffs there. To take the most extreme example, iwlwifi-1000-5.ucode was added in June 2011, but we're still including iwlwifi-1000-3.ucode. Surely we don't need to worry about people booting kernels from ~May 2011 any more?

As I wrote in the commit message, the tightest cutoff we make is around January 2022, for the 22000 devices, by cutting versions 63 and earlier, leaving 66 as the earliest version we ship. The driver added support for firmware version 66 in September 2021 in Linus' tree - https://github.com/torvalds/linux/commit/851c8e761c393a63d6346b472ae40b4ef74eba1f . So as long as you're booting a kernel from then or later, the driver will use the 66 firmware. At least, that's how I understand it. If I'm wrong and somehow older devices actually need lower firmware versions even if the driver supports newer ones, we'd have to reconsider this.

I would much sooner do this upstream than have a billion lines of exceptions here to manage as it becomes unweildly very quickly as can be seen by this patch alone.

I did start writing it as a patch for upstream, but it gets a bit tricky when we reach the 22000 firmwares, and those are most of the weight. I thought upstream might find this 5.15 cutoff a bit too aggressive, so I figured to do it downstream.

The older stuff we could probably do upstream, yes, but also, it won't change - they're not making any new firmwares for those cards. It's the newer stuff that's likely to change. I wrote it the way I did to hopefully make it not too awful to "maintain" - as long as Intel sticks with the current approach, all that needs to be done is adding new 22000 device IDs when they show up, and bumping the higher end of the loop range when appropriate.

I did also email the Intel folks - I tried to check in with you first but you weren't around that day. Gregory replied and said you had already talked about possibly moving the files to a subdirectory (which I guess would help split them into a separate subpackage, but doesn't help with the size for the installer environment). He seemed positive on the idea of cutting at least some of the firmwares for the older cards upstream, so that'd be a win for sure. He says he's gonna talk it over with some other folks at Intel first and get back to me.

So, you want the still-working Wi-Fi chipsets to stop working?

72XX, 82XX and 9XXX are still used even in new budget-class laptops.

Terrible change. Strongly -1.

So, you want the still-working Wi-Fi chipsets to stop working?

72XX, 82XX and 9XXX are still used even in new budget-class laptops.

Terrible change. Strongly -1.

No, that is absolutely NOT what Adam is proposing, please read and understand before making stupid alarmist comments. There will be no dropping of HW, intel ships multiple versions of firmware, it's dropping old versions of firmware for the various revs of hardware.

before making stupid alarmist comments

Please stop being rude.

There will be no dropping of HW, intel ships multiple versions of firmware, it's dropping old versions of firmware for the various revs of hardware.

Are you sure that that firmware is not needed by "various revs of hardware"?

If Intel ships all these blobs in linux-firmware, then they have a good reason for this, don't they?

before making stupid alarmist comments

Please stop being rude.

There will be no dropping of HW, intel ships multiple versions of firmware, it's dropping old versions of firmware for the various revs of hardware.

Are you sure that that firmware is not needed by "various revs of hardware"?

If Intel ships all these blobs in linux-firmware, then they have a good reason for this, don't they?

No. Intel, and every other vendor, never deletes anything from upstream. The submit firmware at a point in time, they may update it while the hardware is in support, and then they ignore it completely after that.

No. Intel, and every other vendor, never deletes anything from upstream. The submit firmware at a point in time, they may update it while the hardware is in support, and then they ignore it completely after that.

Thanks for the info. I thought they were used by older hardware revisions.

Sorry for the noise. +1 for this change then.

so, we might need to go ahead and merge this...Rawhide netinst images are oversize again thanks to the kernel itself and webkitgtk, and I suspect it may not prove straightforward to shrink those again. This might be the easiest way to get back under size.

I've submitted a patch series to upstream to remove all the obsolete firmware.

https://lore.kernel.org/linux-firmware/20230119204259.507365-1-pbrobinson@gmail.com/T/#u

In the git repo it moved it from 202 firmware @ 248M to 110 firmware @ 132M uncompressed.

I will handle it that way so closing this.

Sure, that will work great, thanks. Will we be able to get it back downstream relatively soon? As per above, neither kernel nor webkitgtk devs seem in a great hurry to shrink their things back down to the previous size, so we are stuck with oversize images at the moment :/ This would definitely get them back under size again.

So for reference comparing the two most common and likely largest:

• iwlax2xx-firmware 67+Mb -> 36Mb installed size
• iwl7260-firmware 10Mb -> 5Mb