[PATCH] wifi: brcmfmac: set F2 blocksize to 256 for BCM43752

[PATCH] wifi: brcmfmac: set F2 blocksize to 256 for BCM43752

[LiangCheng Wang]

The BCM43752 is not reliable with the default 512-byte SDIO function 2
block size: on an i.MX8MP board with an AMPAK AP6275S module at
SDR104 / 200 MHz, an iperf TX stress test kills WLAN within seconds:

  mmc_submit_one: CMD53 sg block write failed -84
  brcmf_sdio_dpc: failed backplane access over SDIO, halting operation

Commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
set up the 43752 like the 4373 for the F2 watermark but missed the F2
block size, which the 4373 limits to 256 bytes. The vendor driver
(bcmdhd) also programs a 256-byte F2 block size for this chip and runs
the same hardware without errors.

Group the 43752 with the 4373, matching the F2 watermark handling.
With this change a 10-minute bidirectional iperf3 soak completes with
zero SDIO errors at ~270 Mbit/s in each direction.

Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
Cc: stable@vger.kernel.org # <= 6.16 needs the CYPRESS_43752 id name
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
---
The failure was isolated by testing combinations of scatter-gather
support and F2 block size, all at SDR104 / 200 MHz, with an iperf
multi-stream stress test plus a 5-10 minute bidirectional iperf3 soak:

  sg/glom  F2 blksz  result
  on       512       fatal halt within seconds (CMD53 write -84,
                     "failed backplane access", wlan dead)
  txglom off, 512    survives, but ~14 recoverable CMD53 errors/min
  rx glom on
  off      512       firmware PSM watchdog reset after ~3 minutes
  off      256       0 errors, but TX limited to ~142 Mbit/s
  on       256       0 errors, RX 265 / TX 273 Mbit/s (this patch)

So the corruption tracks the 512-byte block size, not scatter-gather;
glomming only amplifies it. The vendor bcmdhd driver logging "set
sd_f2_blocksize 256" at probe is what pointed at the missing override.

The BCM43751 shares the 43752 firmware handling and F2 watermark case
and may need the same fix, but I have no 43751 hardware to verify.

Tested on:
- i.MX8MP (usdhc SDIO host, AMPAK AP6275S module) with Linux kernel
  6.12.34 plus this patch

The touched code is unchanged between 6.12 and the current tree apart
from the 74e2ef72bd4b ("wifi: brcmfmac: fix 43752 SDIO FWVID
incorrectly labelled as Cypress (CYW)") rename; stable trees before it
need the old SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752 name to build.
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index d24b80e492e084160e1d085b8c20242de3e07c28..3f7a05c4d27ad4c284a6ecc7f0b014a1e985526d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -911,6 +911,7 @@ int brcmf_sdiod_probe(struct brcmf_sdio_dev *sdiodev)
 		return ret;
 	}
 	switch (sdiodev->func2->device) {
+	case SDIO_DEVICE_ID_BROADCOM_43752:
 	case SDIO_DEVICE_ID_BROADCOM_CYPRESS_4373:
 		f2_blksz = SDIO_4373_FUNC2_BLOCKSIZE;
 		break;

---
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
change-id: 20260713-b43752-f2-blksz-efda1de3ede9

Best regards,
-- 
LiangCheng Wang <zaq14760@gmail.com>

Re: [PATCH] wifi: brcmfmac: set F2 blocksize to 256 for BCM43752

[Arend van Spriel]

On 13/07/2026 10:50, LiangCheng Wang wrote:
> The BCM43752 is not reliable with the default 512-byte SDIO function 2
> block size: on an i.MX8MP board with an AMPAK AP6275S module at
> SDR104 / 200 MHz, an iperf TX stress test kills WLAN within seconds:
> 
>    mmc_submit_one: CMD53 sg block write failed -84
>    brcmf_sdio_dpc: failed backplane access over SDIO, halting operation
> 
> Commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
> set up the 43752 like the 4373 for the F2 watermark but missed the F2
> block size, which the 4373 limits to 256 bytes. The vendor driver
> (bcmdhd) also programs a 256-byte F2 block size for this chip and runs
> the same hardware without errors.
> 
> Group the 43752 with the 4373, matching the F2 watermark handling.
> With this change a 10-minute bidirectional iperf3 soak completes with
> zero SDIO errors at ~270 Mbit/s in each direction.
> 
> Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
> Cc: stable@vger.kernel.org # <= 6.16 needs the CYPRESS_43752 id name

Looks good to me but the stable instruction looks confusion. What do you 
mean. If there is no 43752 support there is no need for this patch, right?

Regards,
Arend

> Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
> ---

Re: [PATCH] wifi: brcmfmac: set F2 blocksize to 256 for BCM43752

[Gokul Sivakumar]

On 07/13, Arend van Spriel wrote:
> On 13/07/2026 10:50, LiangCheng Wang wrote:
> > The BCM43752 is not reliable with the default 512-byte SDIO function 2
> > block size: on an i.MX8MP board with an AMPAK AP6275S module at
> > SDR104 / 200 MHz, an iperf TX stress test kills WLAN within seconds:
> > 
> >    mmc_submit_one: CMD53 sg block write failed -84
> >    brcmf_sdio_dpc: failed backplane access over SDIO, halting operation
> > 
> > Commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
> > set up the 43752 like the 4373 for the F2 watermark but missed the F2
> > block size, which the 4373 limits to 256 bytes. The vendor driver
> > (bcmdhd) also programs a 256-byte F2 block size for this chip and runs
> > the same hardware without errors.
> > 
> > Group the 43752 with the 4373, matching the F2 watermark handling.
> > With this change a 10-minute bidirectional iperf3 soak completes with
> > zero SDIO errors at ~270 Mbit/s in each direction.
> > 
> > Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
> > Cc: stable@vger.kernel.org # <= 6.16 needs the CYPRESS_43752 id name
> 
> Looks good to me but the stable instruction looks confusion. What do you
> mean. If there is no 43752 support there is no need for this patch, right?

Arend, one year back, from Infineon we had submitted a patch [1] to correct
the vendor ownership of 43752. i.e, SDIO_DEVICE_ID_BROADCOM_CYPRESS_4373 got
replaced with SDIO_DEVICE_ID_BROADCOM_43752. 

So in the older kernel versions like v6.16.x which does not have patch [1],
the 43752 support exists, but with SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752.
So his instruction is to, again replace SDIO_DEVICE_ID_BROADCOM_4373 with
SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752 in his patch [2] while cherry-picking
to the older stable trees.

Rather than that, I would suggest to cherry-pick both the patches [1] & [2]
to stable trees, since the new patch [2] is dependent on existing patch [1].

[1] https://lore.kernel.org/linux-wireless/20250724101136.6691-1-gokulkumar.sivakumar@infineon.com/
[2] https://lore.kernel.org/linux-wireless/20260713-b43752-f2-blksz-v1-1-8697fcfeaef4@gmail.com/

Gokul

> > Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
> > ---
> 

Re: [PATCH] wifi: brcmfmac: set F2 blocksize to 256 for BCM43752

[Arend van Spriel]

Op 13 juli 2026 13:52:28 schreef Gokul Sivakumar 
<gokulkumar.sivakumar@infineon.com>:

> On 07/13, Arend van Spriel wrote:
>> On 13/07/2026 10:50, LiangCheng Wang wrote:
>>> The BCM43752 is not reliable with the default 512-byte SDIO function 2
>>> block size: on an i.MX8MP board with an AMPAK AP6275S module at
>>> SDR104 / 200 MHz, an iperf TX stress test kills WLAN within seconds:
>>>
>>> mmc_submit_one: CMD53 sg block write failed -84
>>> brcmf_sdio_dpc: failed backplane access over SDIO, halting operation
>>>
>>> Commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
>>> set up the 43752 like the 4373 for the F2 watermark but missed the F2
>>> block size, which the 4373 limits to 256 bytes. The vendor driver
>>> (bcmdhd) also programs a 256-byte F2 block size for this chip and runs
>>> the same hardware without errors.
>>>
>>> Group the 43752 with the 4373, matching the F2 watermark handling.
>>> With this change a 10-minute bidirectional iperf3 soak completes with
>>> zero SDIO errors at ~270 Mbit/s in each direction.
>>>
>>> Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
>>> Cc: stable@vger.kernel.org # <= 6.16 needs the CYPRESS_43752 id name
>>
>> Looks good to me but the stable instruction looks confusion. What do you
>> mean. If there is no 43752 support there is no need for this patch, right?
>
> Arend, one year back, from Infineon we had submitted a patch [1] to correct
> the vendor ownership of 43752. i.e, SDIO_DEVICE_ID_BROADCOM_CYPRESS_4373 got
> replaced with SDIO_DEVICE_ID_BROADCOM_43752.
>
> So in the older kernel versions like v6.16.x which does not have patch [1],
> the 43752 support exists, but with SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752.
> So his instruction is to, again replace SDIO_DEVICE_ID_BROADCOM_4373 with
> SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752 in his patch [2] while cherry-picking
> to the older stable trees.
>
> Rather than that, I would suggest to cherry-pick both the patches [1] & [2]
> to stable trees, since the new patch [2] is dependent on existing patch [1].

Agreed. Thanks for your guidance.

Regards,
Arend

>
> [1] 
> https://lore.kernel.org/linux-wireless/20250724101136.6691-1-gokulkumar.sivakumar@infineon.com/
> [2] 
> https://lore.kernel.org/linux-wireless/20260713-b43752-f2-blksz-v1-1-8697fcfeaef4@gmail.com/
>
> Gokul
>
>>> Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
>>> ---

Re: [PATCH] wifi: brcmfmac: set F2 blocksize to 256 for BCM43752

[LiangCheng Wang]

Hi Arend,

On 13/07/2026 12:51, Arend van Spriel wrote:
> Looks good to me but the stable instruction looks confusion. What do you
> mean. If there is no 43752 support there is no need for this patch, right?

Thank you for the review, and thanks Gokul for the detailed
explanation - that is exactly what I meant, and sorry the annotation
was not clearer. To summarize: 43752 support has been present since
v5.15 (commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and
initialization")), under the SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752 id
name. Commit 74e2ef72bd4b ("wifi: brcmfmac: fix 43752 SDIO FWVID
incorrectly labelled as Cypress (CYW)"), which landed in v6.18,
renamed it to SDIO_DEVICE_ID_BROADCOM_43752.

I also have to correct myself here: the boundary in the annotation
should have been "<= 6.17" rather than "<= 6.16", since the rename
only landed in v6.18. Apologies for the extra confusion.

Gokul's suggestion of cherry-picking the rename patch together with
this one into the stable trees sounds cleaner to me than editing the
id name while backporting, so I would be glad to go with that.

If it helps, I would be happy to send a v2 with the stable annotation
in the prerequisite format from
Documentation/process/stable-kernel-rules.rst:

  Cc: <stable@vger.kernel.org> # 74e2ef72bd4b: wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress (CYW)

Please let me know if you would prefer that, or if the patch is fine
to take as is.

Best regards,
LiangCheng

Re: [PATCH] wifi: brcmfmac: set F2 blocksize to 256 for BCM43752

[Arend van Spriel]

Op 14 juli 2026 04:29:16 schreef LiangCheng Wang <zaq14760@gmail.com>:

> Hi Arend,
>
> On 13/07/2026 12:51, Arend van Spriel wrote:
>> Looks good to me but the stable instruction looks confusion. What do you
>> mean. If there is no 43752 support there is no need for this patch, right?
>
> Thank you for the review, and thanks Gokul for the detailed
> explanation - that is exactly what I meant, and sorry the annotation
> was not clearer. To summarize: 43752 support has been present since
> v5.15 (commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and
> initialization")), under the SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752 id
> name. Commit 74e2ef72bd4b ("wifi: brcmfmac: fix 43752 SDIO FWVID
> incorrectly labelled as Cypress (CYW)"), which landed in v6.18,
> renamed it to SDIO_DEVICE_ID_BROADCOM_43752.
>
> I also have to correct myself here: the boundary in the annotation
> should have been "<= 6.17" rather than "<= 6.16", since the rename
> only landed in v6.18. Apologies for the extra confusion.
>
> Gokul's suggestion of cherry-picking the rename patch together with
> this one into the stable trees sounds cleaner to me than editing the
> id name while backporting, so I would be glad to go with that.
>
> If it helps, I would be happy to send a v2 with the stable annotation
> in the prerequisite format from
> Documentation/process/stable-kernel-rules.rst:
>
>  Cc: <stable@vger.kernel.org> # 74e2ef72bd4b: wifi: brcmfmac: fix 43752 SDIO 
>  FWVID incorrectly labelled as Cypress (CYW)
>
> Please let me know if you would prefer that, or if the patch is fine
> to take as is.

Cc: instructions to stable should stick to the stable-kernel-rules format 
if possible. I suspect there is a bit of scripting sifting through it.

Regards,
Arend

> Best regards,
> LiangCheng