New iwn firmware & upgrade procedure

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

I'm testing upgrading my Lenovo T430 laptop whish has

[     1.042448] iwn0 at pci2 dev 0 function 0: Intel Centrino Advanced-N 6205 WiFi (rev. 0x34)
[     1.042448] iwn0: interrupting at msi3 vec 0
[     1.042448] iwn0: MIMO 2T2R, MoW, address a4:4e:31:e4:43:a8

for wireless network hardware.  This laptop now runs 9.99.92 from
november 2021, and has the following relevant-ish firmware files:

/libdata/firmware/if_iwn/iwlwifi-6000-4.ucode
/libdata/firmware/if_iwn/iwlwifi-6000g2a-5.ucode
/libdata/firmware/if_iwn/iwlwifi-6000g2b-6.ucode
/libdata/firmware/if_iwn/iwlwifi-6050-5.ucode

Now, when I booted the latest 9.99.97 kernel from nyftp.netbsd.org, I
get in the kernel log:

[     7.371439] iwn0: autoconfiguration error: could not get firmware handle iwlwifi-6000g2a-6.ucode
[     7.371439] iwn0: autoconfiguration error: could not read firmware

If I look at what's in the 'base' set in -current, I find

./libdata/firmware/if_iwn/iwlwifi-6000-4.ucode
./libdata/firmware/if_iwn/iwlwifi-6000g2a-6.ucode
./libdata/firmware/if_iwn/iwlwifi-6000g2b-6.ucode
./libdata/firmware/if_iwn/iwlwifi-6050-5.ucode

This raises a couple of questions:

1) Could the if_iwn driver fall back to using the 6000g2a-5 microcode
   without any code changes?  (My gut feeling says "yes", but I have
   no existence proof of that.)

2) Should I have to extract parts of user-land in order to make the
   wireless driver in the kernel work as intended?

I've from habit always done NetBSD upgrades as "extract kernel,
install, reboot, and then verify that things work as intended before
committing to the new installation by extracting userland, and then
lastly do the etc set update (and perhaps a final reboot)", and have
only recently larned to put "extract the new modules set" before the
first kernel reboot.

Should the wireless firmware go into a different set which we also
learn the habit of extracting before reboot of the kernel?

I have the impression that we generally frown upon a lack of backward
compatibility, and kernel features depending on upgraded user-land,
and forcing a firmware blob upgrade to make the new kernel work has a
non-zero chance of making the old (previous) kernel no longer work as
intended as a fallback...

What about GPU firmware?  I see it also has a new set all of its own,
and some of the related compatibility questions can be raised there.

Regards,

- Håvard