Re: [RESEND] brcmfmac support for BCM4359 sdio on arm64 ??

[Arend Van Spriel <arend.vanspriel@broadcom.com>]

On 6/8/2019 5:39 AM, Christian Hewitt wrote:
> Hello Arend,
> 
> Last October Christoph Müllner reported BCM4359 SDIO issues here: https://www.spinics.net/lists/linux-wireless/msg178783.html but the investigation stalled after the needs/timescale of his project forced a change to a different (working) module.
> 
> BCM4359 is being used in an increasing number of Amlogic devices the Kodi focussed distro LibreELEC supports. I’m one of the maintainers for the distro and I’d like to assist/resume the investigation.
> 
> To recap: using changes from Wright Feng that can be found here https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0050-brcmfmac-Add-support-for-BCM4359-SDIO-chipset.patch result in the BCM4359 device being identified but firmware/nvram loading fails:
> 
> [    8.557929] brcmfmac: F1 signature read @0x18000000=0x17294359
> [    8.562087] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
> [    8.775655] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
> [    8.775667] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f0c0
> [    8.775670] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed

It seems to fail when reading back the nvram file to assure it was 
downloaded properly.

> See: http://ix.io/1KfY for the full dmesg output on 5.1-rc1 kernel including a splat that may or may not be related/relevant. I am using firmware and nvram files from https://github.com/LibreELEC/brcmfmac_sdio-firmware which match files found in several other github and public repo locations. The firmware/nvram are reported working in Android.

The splat could be relevant. Maybe try the patch below to get actual 
values that are checked in the WARN_ON.

> BCMDHD is also reported working with commits here: https://gitlab.com/baylibre/amlogic/atv/linux/commits/narmstrong/v5.1/aml/integ-5.1-bcmdhd but LibreELEC needs to support many different boards (with many different SDIO modules) from a single OS image, so BCMDHD is not the solution we need.
> 
> One additional patch I spotted mentioning BCM4359 (also from Wright Feng) was https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0073-non-upstream-reset-two-D11-cores-if-chip-has-two-D11.patch but it makes no difference (the dmesg log above is with this patch applied).
> 
> I don’t write code but am happy to build test kernels with suggested patches or explicit instructions. I’ve also CC’d LibreELEC colleague and linux-amlogic maintainer Neil Armstrong who can assist. NB: If direct access to hardware would help progress things I can easily organise remote access or get board samples shipped.
> 
> How can we resume the investigation?

Let's try one step at a time ;-)

Regards,
Arend
---
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/driver
index fc12598..e9b0986 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -772,7 +772,8 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev 
*sdiod
                       sdiodev->settings->bus.sdio.txglomsz);
         nents += (nents >> 4) + 1;

-       WARN_ON(nents > sdiodev->max_segment_count);
+       WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u, 
host_max_seg=
+            sdiodev->max_segment_count, host->max_segs, nents);

         brcmf_dbg(TRACE, "nents=%d\n", nents);
         err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
q