Re: [PATCH v3 3/9] brcmfmac: firmware: Do not crash on a NULL board_type

[Hector Martin]

On 20/01/2022 06.45, Andy Shevchenko wrote:
> On Mon, Jan 17, 2022 at 4:30 PM Hector Martin <marcan@xxxxxxxxx> wrote:
>>
>> This unbreaks support for USB devices, which do not have a board_type
>> to create an alt_path out of and thus were running into a NULL
>> dereference.
> 
> In v5.16 we have two call sites:
> 
> 1.
>   if (cur->type == BRCMF_FW_TYPE_NVRAM && fwctx->req->board_type) {
>     ...
>     alt_path = brcm_alt_fw_path(cur->path, fwctx->req->board_type);
> 
> 2.
>   alt_path = brcm_alt_fw_path(first->path, fwctx->req->board_type);
>   if (alt_path) {
>     ...
> 
> Looking at them I would rather expect to see (as a quick fix, the
> better solution is to unify those call sites by splitting out a common
> helper):
> 
>   if (fwctx->req->board_type) {
>     alt_path = brcm_alt_fw_path(first->path, fwctx->req->board_type);
>   else
>     alt_path = NULL;
>    ...
> 

Since brcm_alt_fw_path can fail anyway, and its return value is already
NULL-checked, it makes sense to propagate the NULL board_path there
rather than doing it at all the callsites. That's a common pattern, e.g.
the entire DT API is designed to accept NULL nodes. That does mean that
the first callsite has a redundant NULL check, yes, but that doesn't hurt.

This is all going to change with subsequent patches anyway; the point of
this patch is just to fix the regression.

-- 
Hector Martin (marcan@xxxxxxxxx)
Public Key: https://mrcn.st/pub