mikeb mikeb has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/31225 )
Change subject: src/mainboard/lenovo/g505s/Kconfig: disable DRIVERS_INTEL_WIFI by default ......................................................................
Patch Set 2:
(1 comment)
.
It doesn't matter how small the chance is. It can hurt if the option is set to `n` falsely. But can't if set to `y`.
It consumes some kilobytes at CBFS and adds extra complexity, so from my point of view it would be better if this doesn't stay as default 'y'. Of course if I will see at least one owner of coreboot'ed G505S with Intel WiFi, this will be a good reason to consider abandoning/reverting this change. However I haven't seen anyone who could suffer from this default 'n'.
and those who upgraded to coreboot are security conscious enough to choose ath9k over intel.
You are confusing software freedom with security.
To me they go hand in hand because the proprietary closed source firmware could contain the evil backdoors, while if the sources are open there is significantly less chance of it. By the way, a lot of G505S people are using security-inclined Qubes OS as their primary distro, and they went through the trouble of finding/refurbishing this laptop because they see that more software freedom at their computer's firmware automatically means much better security.
. Anybody is already free to disable it if they don't need it.
The point of my recent commits is to minimize the amount of local configurations the people need to do at their freshly cloned coreboot. If no-one is using G505S with Intel WiFi, there are no reasons for it to stay as default 'y', but I could change my point of view if I would see at least one person with such a system configuration.
https://review.coreboot.org/#/c/31225/2//COMMIT_MSG Commit Message:
https://review.coreboot.org/#/c/31225/2//COMMIT_MSG@13 PS2, Line 13: have a much better software freedom status and are the preferred choice.
Um, I know that page... the only reference it quotes seems to predate […]
As far as I know there haven't been any significant architecture changes between the various chips of ath9k family and they enjoy the same freedom status (unlike the problematic ath10k). Also, it seems that ath9k modules contain only 4 kilobytes EEPROM with ART and other settings and they don't have a ROM with a fully fledged proprietary firmware controlling it, so the chips at these modules are controlled completely by this opensource driver - which is very easy to update if there would be any security problems. While for ath9k_htc (USB modules, not PCIe) there is a ROM with firmware - but it is unactive if your driver loads the open source ath9k_htc firmware officially released by Atheros and available at Github.
P.S. Sorry I can't understand why every chip in existence requires a ROM to function; depending on the architecture it could simply obey the driver's commands. I think it could be "hardwired" inside the hardware without any ROM that chip will be loading the instructions starting from i.e. 0x1000 offset at its' RAM, and driver could be simply putting the various instructions there, software handle the interrupts coming from the physical IRQ lines of this chip and read/write the chip's registers to handle them.