09.08.2021 11:23, Arend van Spriel пишет: > On 8/8/2021 8:05 PM, Dmitry Osipenko wrote: >> From: Linus Walleij <linus.walleij@xxxxxxxxxx> >> >> The patch that would first try the board-specific firmware >> had a bug because the fallback would not be called: the >> asynchronous interface is used meaning request_firmware_nowait() >> returns 0 immediately. >> >> Harden the firmware loading like this: >> >> - If we cannot build an alt_path (like if no board_type is >> specified) just request the first firmware without any >> suffix, like in the past. >> >> - If the lookup of a board specific firmware fails, we get >> a NULL fw in the async callback, so just try again without >> the alt_path from a dedicated brcm_fw_request_done_alt_path >> callback. >> >> - Drop the unnecessary prototype of brcm_fw_request_done. >> >> - Added MODULE_FIRMWARE match for per-board SDIO bins, making >> userspace tools to pull all the relevant firmware files. > The original idea was to setup the path names in > brcmf_fw_alloc_request() function, but with the introduction of the > board_type for NVRAM files that was abandoned and we cook up alternative > paths. Now similar is done for the firmware files. So I would want to > rework the code, but for now I am going with Linus's/Your fix for the > sake of having the regression more or less quickly resolved. Thanks, indeed it could be improved further later on. > You reported an issue earlier where the firmware callback was called > from the probe context causing it to hang and it is not clear to me > whether that is fixed with this version of the patch. It's independent minor problem that can't be easily reproduced in practice and seems it existed for a long time. It's not fixed by this patch.
