From: LiangCheng Wang <zaq14760@gmail.com> Date: 2026-07-13 08:51:00
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(+)
From: Arend van Spriel <arend.vanspriel@broadcom.com> Date: 2026-07-13 10:51:46
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>
---
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
quoted
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
---
From: LiangCheng Wang <zaq14760@gmail.com> Date: 2026-07-14 02:29:16
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: [off-list ref] # 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
From: Arend van Spriel <arend.vanspriel@broadcom.com> Date: 2026-07-14 16:54:08
Op 13 juli 2026 13:52:28 schreef Gokul Sivakumar [off-list ref]:
On 07/13, Arend van Spriel wrote:
quoted
On 13/07/2026 10:50, LiangCheng Wang wrote:
quoted
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].
From: Arend van Spriel <arend.vanspriel@broadcom.com> Date: 2026-07-14 17:03:17
Op 14 juli 2026 04:29:16 schreef LiangCheng Wang [off-list ref]:
Hi Arend,
On 13/07/2026 12:51, Arend van Spriel wrote:
quoted
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: [off-list ref] # 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