linux-kernel - Re: [PATCH RESEND] brcmfmac: Add an error log for brcmf_sdiod

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] [day] [month] [year] [list]

Message-ID: <0030b46b-d8c2-4a85-9725-4d08b5787830@broadcom.com>
Date: Wed, 23 Jul 2025 10:24:46 +0200
From: Arend van Spriel <arend.vanspriel@...adcom.com>
To: Wentao Liang <vulab@...as.ac.cn>
Cc: kvalo@...nel.org, sebastian.reichel@...labora.com,
 erick.archer@...look.com, megi@....cz, linux-wireless@...r.kernel.org,
 brcm80211@...ts.linux.dev, brcm80211-dev-list.pdl@...adcom.com,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] brcmfmac: Add an error log for brcmf_sdiod_ramrw()

On 4/14/2025 9:42 AM, Wentao Liang wrote:
> The function brcmf_sdio_buscore_activate() calls the function
> brcmf_sdiod_ramrw(), but does not check its return value. Log
> the error message to prevent silent failure if the function fails.

Johannes delegated this to me in patchwork so catching up on what was 
already forgotten. Sorry about that.

The likelihood that writing the reset vector in device memory fails is 
next to nothing, because this step is done after we have written the 
firmware and nvram into device memory. Any issue accessing device memory 
would have cause a failure in those steps. So I suggest to drop this patch.

Regards,
Arend