fwget: update wireless IDs for rtw88/89, ath1xk, mt76 and add iwlwifi

[bz]

Summary

Update and add (new) PCI IDs for Realtek rtw88/89, Mediatek 7996/7925,
QCA ath1xk, and add Intel iwlwifi IDs.

Rather than using a package per driver add fine(r) grained flavors
even though it is a lot more likely to break in some cases.

For Intel we need a great level of detail to match PCI IDs so also pass
the full pciconf -l line to into the pci_* files as "$2" to have access
to these.

[manu]

wifi-firmware-iwlwifi-kmod doesn't seems to exists ?
Also why adding one big package and then do a case/esac based on id if you're not going to add flavors ?

[bz]

In D44918#1024287, @manu wrote:

wifi-firmware-iwlwifi-kmod doesn't seems to exists ?

It is coming with the ports update currently in the makings. I am currently testing the various versions (given in main we can install "bin" files now and no longer need .ko).

Also why adding one big package and then do a case/esac based on id if you're not going to add flavors ?

Because Intel iwlwifi/mvm splattered the IDs massively around. There's not a single "deviceID" to check. Sometimes it is even the "subdevice" which tells instead of "deviceID". It's a big mess. If you check man iwlwififw you can also see it. There are even some cases we cannot detected by PCI IDs, which will fall through the grid currently. But intel_networking could also be iwn(4) or even Ethernet and I don't want to catch those by accident.

The fact that they are grouped currently is more for convenience and for a next step once I also sort the .pnvm files out along. But I'd prefer to do one step a time as otherwise we get nowhere now. The first step is to get them out of src and then the installer ready for it.

[manu]

In D44918#1024358, @bz wrote:

In D44918#1024287, @manu wrote:

wifi-firmware-iwlwifi-kmod doesn't seems to exists ?

It is coming with the ports update currently in the makings. I am currently testing the various versions (given in main we can install "bin" files now and no longer need .ko).

Do you have a link ?

Also why adding one big package and then do a case/esac based on id if you're not going to add flavors ?

Because Intel iwlwifi/mvm splattered the IDs massively around. There's not a single "deviceID" to check. Sometimes it is even the "subdevice" which tells instead of "deviceID". It's a big mess. If you check man iwlwififw you can also see it. There are even some cases we cannot detected by PCI IDs, which will fall through the grid currently.

But most can be checked by pciid no ? I don't see why you want people to install ~31MB of firmware files when they only need a few kbs.

But intel_networking could also be iwn(4) or even Ethernet and I don't want to catch those by accident.

We could add a force option to fwget to get firmware for alternate drivers (or someway to specify a driver, this could be useful for radeon/amdgpu for overlapping gpus).

The fact that they are grouped currently is more for convenience and for a next step once I also sort the .pnvm files out along. But I'd prefer to do one step a time as otherwise we get nowhere now. The first step is to get them out of src and then the installer ready for it.

Well no, it's better to makes things properly at first.

[bz]

Update to fine(r) grained flavored packages.

I'll put the ports changes into review tomorrow.

[bz]

usr.sbin/fwget/pci/pci_network_intel

27

I should update this bit as it is no longer the full magic needed; should more likely end up with the driver somewhere to help us update this list.

[bz]

usr.sbin/fwget/pci/pci_network_qca

35

These two need to be two calls into addpkg() likely to make the duplication detection work properly.

[imp]

I don't suppose that yhese could be generated automatically? It's a huge table to maintain by hand...

[bz]

In D44918#1024544, @imp wrote:

I don't suppose that yhese could be generated automatically? It's a huge table to maintain by hand...

Well as some hints in comments indicate some of this can be generated based on one or two scripts; you need bits to select fw files to flavors in ports, you need bits to select PCI IDs to flavors, ... you need that possibly for every branch as things may be different as newer firmware version not accepted by older driver, ... QCA I simply could not find any way to hack it up. For mt76 I have parts; for iwlwifi I need the driver loaded to get the proper list it "thinks" it has, + a script to deal with the firmware repo what is there + a script to bring both together for here. Realtek is currently simply "simple". And for fun parts: you do not always have all the firmware but they are already referenced in the driver for PCI IDs, or you have firmware (needed) used but not referenced by the driver as such but puzzled together.

If it was almost 6AM now I would say "PAAAAAAAAAIIIIIIIIIIIINNNNNNNNNNful" but hey, ext step will be to add all this to the installer...

[imp]

So I'm not saying we need it now, but we likely need to know if we can... get some sleep

[manu]

Looks better now, thanks a lot.
Do you have a review for the ports change ?

[bz]

In D44918#1024641, @manu wrote:

Looks better now, thanks a lot.

Thanks a lot for pushing me to do it now. Was painful but now it is done.

Do you have a review for the ports change ?

The first stage of updates comes the next hours after I finished a rebase and a once-over. I still also have to test a few combinations but I assume review can happen the same time.

[bz]

• Fix the two QCA entries which depend on two packages
• Update the comments on Intel iwlwifi removing some initial logic in favor of a script (it is currently two but I'll try to clean it up and add it either to src or ports to generate both the fwget case pattern and the ports flavor->firmware files list generation)

[bz]

Ports change part I here: https://reviews.freebsd.org/D44945

[bz]

usr.sbin/fwget/pci/pci_network_qca

33–52

FLAVORS need to be [a-z_]*

[bz]

Update one more time to (hopefully) have all ports/pkackage flavors in lower case.
Also the new files are all script generated.
The scripts will be pushed to github with the next update there before going into main.

[bz]

Re-genertae them based on updated scripts.

[bz]

@manu if you are (still) happy with the updated versions, the ports/packages are coming as well (see D44945).
I think we are getting more "stable" now in between supported versions and "noise".
Also while this adds forward matching at least for Intel (the firmware flavor for sc does not exist as the firmware is not public yet), shipping it like this means that after a release we can add the firmware package and the driver and fwget will already support it.