rtlwifi false positive(?)

[Alexandre Oliva]

On Oct 28, 2020, "a.reviewer1234 at yahoo.com" <a.reviewer1234 at yahoo.com> wrote:

> I think this may be a false positive. It appears to be an array of
> channel frequencies for 5GHz.

You may confirm whether this is the case by running
deblob-check --print-marked-false-positives

You'll likely find channel5g recognized as a false positive, i.e., not
as something that needs cleaning up.

I suppose you may be assuming we found something problematic in
rtlwifi/core.c and are looking for the reason.

It's not any blob or apparent blob in there.  It's just infrastructure
that other blob-loading drivers rely on.

See, the only thing we change in RTLWIFI is the request_firmware call in
rtlwifi/core.c to reject_firmware.  That's what the 'reject_firmware'
command does.

Several other drivers under rtlwifi rely on that request/reject_firmware
to request non-Free firmware, and there aren't any uses thereof to load
Free firmware.  That's why we disable it.

So, there's nothing wrong with code conditioned on RTLWIFI per se, it's
just the uses thereof that are not FSDG-compliant, and require adjusting
RTLWIFI to deal with the disabled blob loading.

-- 
Alexandre Oliva, happy hacker
https://FSFLA.org/blogs/lxo/
Free Software Activist
GNU Toolchain Engineer