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@xxxxxxxxxxxx>:

> 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@xxxxxxxxxxxxxxx # <= 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@xxxxxxxxxxxx/
> [2] 
> https://lore.kernel.org/linux-wireless/20260713-b43752-f2-blksz-v1-1-8697fcfeaef4@xxxxxxxxx/
>
> Gokul
>
> > > Signed-off-by: LiangCheng Wang <zaq14760@xxxxxxxxx>
> > > ---