linux-kernel - Re: [PATCH 9/9] brcmfmac: use request_firmware_nowait2 to load firmware without warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 21 Apr 2018 10:19:42 +0300
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Andres Rodriguez <andresx7@...il.com>
Cc:     linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
        mcgrof@...nel.org, alexdeucher@...il.com,
        ckoenig.leichtzumerken@...il.com, arend.vanspriel@...adcom.com,
        linux-wireless@...r.kernel.org
Subject: Re: [PATCH 9/9] brcmfmac: use request_firmware_nowait2 to load firmware without warnings

Andres Rodriguez <andresx7@...il.com> writes:

>>> +				      fwctx->nvram_name, fwctx->dev,
>>> +				      GFP_KERNEL, fwctx,
>>>   				      brcmf_fw_request_nvram_done);
>>>     	/* pass NULL to nvram callback for bcm47xx fallback */
>>> @@ -547,7 +548,7 @@ int brcmf_fw_get_firmwares_pcie(struct device *dev, u16 flags,
>>>   	fwctx->domain_nr = domain_nr;
>>>   	fwctx->bus_nr = bus_nr;
>>>   -	return request_firmware_nowait(THIS_MODULE, true, code, dev,
>>> +	return request_firmware_nowait2(THIS_MODULE, true, false, code, dev,
>>>   				       GFP_KERNEL, fwctx,
>>>   				       brcmf_fw_request_code_done);
>>>   }
>>
>> Also the number two in the function name is not really telling anything.
>> I think that something like request_firmware_nowait_nowarn() would be
>> better, even if it's so ugly.
>>
>
> The 2 is meant to signify that this is an new version of the api with
> different parameters.

Ah, I missed that. I didn't have time to review your patches in detail,
just looked at the wireless patches.

> I don't think we need to codify into the name what the new parameters
> mean (mostly because when a 2 version of an api is implemented, usage
> of the original version tends to be discouraged).

Yeah, makes sense now.

-- 
Kalle Valo