This is not entirely true. The ATH9k is based around a Tensilica Xtensa core and has a firmware, but this firmware resides on chip and not as blob in userspace. The Ar3k, which is the Bluetooth part, does not require a firmware but a rather small parameter blob. It can also use an external firmware to update parts of the built-in ROM (often called “RAM patch”) but that’s not strictly necessary. Also the parameter block is not strictly necessary. I once patched the load of it out of the kernel and Bluetooth will then work with the hardwired parameters instead - though YMMV since some Bluetooth modules (I do not know if the QCNFA222 does) use such kind of parameters to e.g. control WIFi/Bluetooth coexistence, which could result in only either one of the two working at a given time.
I am not so sure about this patent argument. This was one that was also given for years for GPUs and why manufacturers would not create free drivers for them. Look what happened - nothing. By now we have blob free drivers for quite a bunch of GPUs, for some others free drivers with blobs and no huge patent litigation has happened.
Yes, all radio stuff is a heavy patent mine field area but these firmware or drivers do not contribute much to proofs for or against patent infringement in practice, it seems.
I have talked to many manufacturers over the course of the past years and in most cases not releasing more as open source has more to do with unproven fear of everything and less concrete risk assessment. Very often you also encounter the “Oh, then we loose our business advantage!” argument, which IMHO is plain false. I do not know of any case in the industry where open source would have been detrimental for a chip maker’s business. Not happening.
But there are more profound reasons one could give, especially for radios. The firmware is usually the last barrier before full control over the radio, especially the transmitting part. All radio is regulated, especially radio transmissions are pretty heavily regulated. Even the 2.4GHz and 5GHz spectrums are ISM spectrums for free use they are not unregulated. Manufacturers must make sure that regulations are met. In the recent years more regulations and laws or law like regulations have been passed that require manufacturers to make sure that users can not bypass anything that prevents them from regulatory compliance. Since you do not and in most cases can not safely prevent this in hardware, you do this in software, namely the firmware.
As far as I know all the radio parts are still not open and there is also little intention to do so. What was done is to hack open the Linux system that is actually running on the modem module - which is cool! But this is still far from “reverse engineering the firmware”. All the radio and a lot of other parts are still used as-is with blobs and that likely not to change.
WiFi cards in contrast are much more primitive / simpler than a cellular modem so IMHO that can not be really compared.
The only free radio “firmware” implementation I know of is the NIMBLE BLE Bluetooth stack which implements everything for the Nordic semiconductor nRF52xxx chips, including full radio control - in contrast e.g. to the famous ESP chips where SDKs like Arduino or the Espressif native IDK/ADK include larger binary only libraries which implement the radio engine and AFAIK there is no open source re-implementation for these yet.
I think we have to arrange ourselves with binary blob firmares somehow. I frankly do not mind them, as long as some requirements are met:
- firmware blobs must not be executed on the main CPU that also runs the operating system - that would be a string security concern
- firmware blobs must come with a perpetual license to redistribute the blob as part of anything without any limitation - else OS distributions get a problem
If these two are met, I have no problem with putting a firmware blob onto my SSD and have the kernel load it into the hardware before using it. I would even prefer this over any solution with the firmware hidden in some obscure piece of hardware which I eventually can not update - and also not have a look at that blob, it’s hidden away from my eyes. I have seen firmware licenses that I would not accept, that e.g. limit redistribution to only as part of a bundle with the manufacturer’s hardware. That’s ridiculous and would severely harm distributions, that’s unacceptable. I even think that some of the firmware files in kernel.org’s firmware repo have such a license though no one cares. But it is a dangling sword over everyone’s head and I do not like that. There is also no good reason to limit distribution like that.
Cheers
nicole