Arend van Spriel <arend.vanspr...@broadcom.com> writes: > On 4/20/2018 12:26 PM, Kalle Valo wrote: >> Andres Rodriguez <andre...@gmail.com> writes: >>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c >>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c >>> index 091b52979e03..26db3ebd52dc 100644 >>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c >>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c >>> @@ -503,8 +503,9 @@ static void brcmf_fw_request_code_done(const struct >>> firmware *fw, void *ctx) >>> goto done; >>> >>> fwctx->code = fw; >>> - ret = request_firmware_nowait(THIS_MODULE, true, fwctx->nvram_name, >>> - fwctx->dev, GFP_KERNEL, fwctx, >>> + ret = request_firmware_nowait(THIS_MODULE, true, false, >> >> A perfect example why enums should be in function calls instead of >> booleans, that "true, false" tells nothing to me and it would be time >> consuming to check from headers files what it means. If you had proper >> enums, for example "FIRMWARE_MODE_FOO, FIRMWARE_STATE_BAR", it would be >> immediately obvious for the reader what the parameters are. Of course >> the first boolean was already there before, but maybe change the new >> boolean to an enum? > > I can not fully agree here. While being a bit more descriptive even > with enums wrong enum values can be used due to copy-paste errors for > instance.
Well, you can also copy paste booleans wrong. I would claim that it's even easier to copy paste booleans wrong than enums. > Also when reviewing code, sometime looking up function prototypes and > type definitions are part of the fun. Tools like ctags or elixir > website make it pretty easy. Hehe :) But when reviewing patches ctags doesn't really help. But yeah, booleans vs enums in function parameters is just a matter of taste. I prefer enums but I'm sure there are people who prefer booleans. -- Kalle Valo
