diff mbox

brcmfmac4329-sdio firmware load failed.

Message ID 5A55D325.60805@broadcom.com (mailing list archive)
State RFC
Delegated to: Kalle Valo
Headers show

Commit Message

Arend van Spriel Jan. 10, 2018, 8:47 a.m. UTC
On 1/9/2018 1:51 PM, Kyle Evans wrote:
> This is linux-4.15-rc2 on an ASUS TF101. This device was shipped with
> Android and a custom kernel using bcmdhd. I have taken nvram.txt from
> /system/etc/ on the stock filesystem and copied to
> /lib/firmware/brcm/brcmfmac4329-sdio.txt. Below is the result.

Ok. So far so good as that nvram.txt is indeed what you want to use.
> [    2.729157] brcmfmac: F1 signature read @0x18000000=0x9934329
> [    2.734313] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
> F1@0x080ac, err: -84

The read failure is a bit concerning, but I ignore it for now.

> [    2.739952] brcmfmac: brcmf_fw_map_chip_to_name: using
> brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
> [    2.965820] brcmfmac mmc0:0001:1: Direct firmware load for
> brcm/brcmfmac4329-sdio.clm_blob failed with error -2

Expected as you did not put a clm_blob file in /lib/firmware/brcm/. 
However, ...

> [    2.969658] brcmfmac mmc0:0001:1: Falling back to user helper
> [   64.489695] brcmfmac: brcmf_c_process_clm_blob: request CLM blob file
> failed (-11)

...in one of the review cycles for the CLM blob feature it was made 
clear that this should not result in a probe failure...

> [   64.489720] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file
> failed, -11
> [   64.489739] brcmfmac: brcmf_bus_started: failed: -11

... but it does bail out. Turns out the driver is checking for a 
specific error code -ENOENT (-2) and not -EAGAIN(-11). A patch has been 
submitted for it earlier [1], but it was rejected. I have taken another 
stab at it (see below). Let me know if it works for you.

> [   64.489783] brcmfmac: brcmf_sdio_firmware_callback: dongle is not
> responding
> [   64.596281] [<c061fd98>] (device_release_driver_internal) from
> [<c068f394>] (brcmf_sdio_firmware_callback+0x244/0x5b8)
> [   64.596500] [<c068f394>] (brcmf_sdio_firmware_callback) from
> [<c0686870>] (brcmf_fw_request_nvram_done+0x1cc/0x73c)
> [   64.596716] [<c0686870>] (brcmf_fw_request_nvram_done) from
> [<c063337c>] (request_firmware_work_func+0x3c/0x64)

This stack trace is from a driver bug that has been fixed in later -rc [2].

Regards,
Arend

[1] https://patchwork.kernel.org/patch/10106571/
[2] https://patchwork.kernel.org/patch/10075091/

---

         chunk_buf = kzalloc(sizeof(*chunk_buf) + MAX_CHUNK_LEN - 1, 
GFP_KERNEL)

Comments

Kyle Evans Jan. 12, 2018, 8:18 p.m. UTC | #1
Thank you Arend. I updated to master again, v4.15-rc7+, and applied your 
patch. All log snips are grabbed with dmesg|grep -E 'mmc0|brcm', as the 
sdio device is on mmc0.

Without patch [1], for reference...

[    0.000000] Kernel command line: console=tty0 selinux=0 
video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
[    3.952561] mmc0: Invalid maximum block size, assuming 512 bytes
[    4.010466] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci] 
using ADMA
[    4.338545] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
[    4.347098] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[    4.350099] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[    4.378430] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
[    4.388387] mmc0: new SDIO card at address 0001
[    4.401773] brcmfmac: F1 signature read @0x18000000=0x9934329
[    4.407624] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data 
F1@0x080ac, err: -84
[    4.410159] brcmfmac: brcmf_fw_map_chip_to_name: using 
brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
[    4.781374] brcmfmac mmc0:0001:1: Direct firmware load for 
brcm/brcmfmac4329-sdio.clm_blob failed with error -2
[    4.781491] brcmfmac mmc0:0001:1: Falling back to user helper
[   69.601645] brcmfmac: brcmf_c_process_clm_blob: request CLM blob file 
failed (-11)
[   69.601668] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file 
failed, -11
[   69.601685] brcmfmac: brcmf_bus_started: failed: -11
[   69.601728] brcmfmac: brcmf_sdio_firmware_callback: dongle is not 
responding


With patch [1]...

[    0.000000] Kernel command line: console=tty0 selinux=0 
video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
[    3.954628] mmc0: Invalid maximum block size, assuming 512 bytes
[    4.010608] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci] 
using ADMA
[    4.341727] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
[    4.349595] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[    4.352695] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[    4.381292] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
[    4.387377] mmc0: new SDIO card at address 0001
[    4.399393] brcmfmac: F1 signature read @0x18000000=0x9934329
[    4.405883] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data 
F1@0x080ac, err: -84
[    4.407207] brcmfmac: brcmf_fw_map_chip_to_name: using 
brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
[    4.709436] brcmfmac mmc0:0001:1: Direct firmware load for 
brcm/brcmfmac4329-sdio.clm_blob failed with error -2
[    4.709517] brcmfmac mmc0:0001:1: Falling back to user helper
[   69.710122] brcmfmac mmc0:0001:1: Direct firmware load for 
brcm/brcmfmac4329-sdio.clm_blob failed with error -2
[   69.710137] brcmfmac mmc0:0001:1: Falling back to user helper
[  131.054899] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: 
Sep  2 2011 14:48:19 version 4.220.48
[  131.072561] brcmfmac: brcmf_setup_wiphybands: rxchain error (-23)
[  131.388384] brcmfmac: _brcmf_set_multicast_list: Setting 
BRCMF_C_SET_PROMISC failed, -23
[  131.392390] brcmfmac: _brcmf_set_multicast_list: Setting 
BRCMF_C_SET_PROMISC failed, -23
[  131.920861] brcmfmac: _brcmf_set_multicast_list: Setting 
BRCMF_C_SET_PROMISC failed, -23
[  131.924183] brcmfmac: _brcmf_set_multicast_list: Setting 
BRCMF_C_SET_PROMISC failed, -23
[  132.593074] brcmfmac: _brcmf_set_multicast_list: Setting 
BRCMF_C_SET_PROMISC failed, -23
[  133.135973] brcmfmac: _brcmf_set_multicast_list: Setting 
BRCMF_C_SET_PROMISC failed, -23
[  133.138223] brcmfmac: _brcmf_set_multicast_list: Setting 
BRCMF_C_SET_PROMISC failed, -23
[  133.152149] brcmfmac: _brcmf_set_multicast_list: Setting 
BRCMF_C_SET_PROMISC failed, -23
[  134.311983] brcmfmac: _brcmf_set_multicast_list: Setting 
BRCMF_C_SET_PROMISC failed, -23
[  134.458577] brcmfmac: _brcmf_set_multicast_list: Setting 
BRCMF_C_SET_PROMISC failed, -23
[  134.461640] brcmfmac: _brcmf_set_multicast_list: Setting 
BRCMF_C_SET_PROMISC failed, -23
[  134.555048] brcmfmac: _brcmf_set_multicast_list: Setting 
BRCMF_C_SET_PROMISC failed, -23


I can now connect to an AP with the following caveats:

1) It takes about two minutes before the wlan device is available. For a 
long while I didn't think it was working because I would check dmesg and 
check ifconfig -a before the wlan would be present.

2) After reboot I get this nasty error...
[    0.000000] Kernel command line: console=tty0 selinux=0 
video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
[    2.269750] mmc0: Invalid maximum block size, assuming 512 bytes
[    2.330010] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci] 
using ADMA
[    2.645242] mmc0: error -110 whilst initialising SDIO card

Regarding the patch, brcmfmac tries to load a firmware file twice for a 
device which the firmware file does not exist. Is there a know list of 
devices which do not need it that we can use to bypass 
brcmf_c_process_clm_blob()?

Thanks,
Kyle

On 01/10/2018 03:47 AM, Arend van Spriel wrote:
> On 1/9/2018 1:51 PM, Kyle Evans wrote:
>> This is linux-4.15-rc2 on an ASUS TF101. This device was shipped with
>> Android and a custom kernel using bcmdhd. I have taken nvram.txt from
>> /system/etc/ on the stock filesystem and copied to
>> /lib/firmware/brcm/brcmfmac4329-sdio.txt. Below is the result.
> 
> Ok. So far so good as that nvram.txt is indeed what you want to use.
>> [    2.729157] brcmfmac: F1 signature read @0x18000000=0x9934329
>> [    2.734313] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
>> F1@0x080ac, err: -84
> 
> The read failure is a bit concerning, but I ignore it for now.
> 
>> [    2.739952] brcmfmac: brcmf_fw_map_chip_to_name: using
>> brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
>> [    2.965820] brcmfmac mmc0:0001:1: Direct firmware load for
>> brcm/brcmfmac4329-sdio.clm_blob failed with error -2
> 
> Expected as you did not put a clm_blob file in /lib/firmware/brcm/. 
> However, ...
> 
>> [    2.969658] brcmfmac mmc0:0001:1: Falling back to user helper
>> [   64.489695] brcmfmac: brcmf_c_process_clm_blob: request CLM blob file
>> failed (-11)
> 
> ...in one of the review cycles for the CLM blob feature it was made 
> clear that this should not result in a probe failure...
> 
>> [   64.489720] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file
>> failed, -11
>> [   64.489739] brcmfmac: brcmf_bus_started: failed: -11
> 
> ... but it does bail out. Turns out the driver is checking for a 
> specific error code -ENOENT (-2) and not -EAGAIN(-11). A patch has been 
> submitted for it earlier [1], but it was rejected. I have taken another 
> stab at it (see below). Let me know if it works for you.
> 
>> [   64.489783] brcmfmac: brcmf_sdio_firmware_callback: dongle is not
>> responding
>> [   64.596281] [<c061fd98>] (device_release_driver_internal) from
>> [<c068f394>] (brcmf_sdio_firmware_callback+0x244/0x5b8)
>> [   64.596500] [<c068f394>] (brcmf_sdio_firmware_callback) from
>> [<c0686870>] (brcmf_fw_request_nvram_done+0x1cc/0x73c)
>> [   64.596716] [<c0686870>] (brcmf_fw_request_nvram_done) from
>> [<c063337c>] (request_firmware_work_func+0x3c/0x64)
> 
> This stack trace is from a driver bug that has been fixed in later -rc [2].
> 
> Regards,
> Arend
> 
> [1] https://patchwork.kernel.org/patch/10106571/
> [2] https://patchwork.kernel.org/patch/10075091/
> 
> ---
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
> b/driver
> index 6a59d06..f805600 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -182,12 +182,8 @@ static int brcmf_c_process_clm_blob(struct brcmf_if 
> *ifp)
> 
>          err = request_firmware(&clm, clm_name, dev);
>          if (err) {
> -               if (err == -ENOENT) {
> -                       brcmf_dbg(INFO, "continue with CLM data 
> currently prese
> -                       return 0;
> -               }
> -               brcmf_err("request CLM blob file failed (%d)\n", err);
> -               return err;
> +               brcmf_info("no CLM blob. Firmware may still need it.\n");
> +               return 0;
>          }
> 
>          chunk_buf = kzalloc(sizeof(*chunk_buf) + MAX_CHUNK_LEN - 1, 
> GFP_KERNEL)
>
Arend van Spriel Jan. 13, 2018, 9:19 a.m. UTC | #2
On 1/12/2018 9:18 PM, Kyle Evans wrote:
> Thank you Arend. I updated to master again, v4.15-rc7+, and applied your
> patch. All log snips are grabbed with dmesg|grep -E 'mmc0|brcm', as the
> sdio device is on mmc0.

Could you follow the reply convention of not top-posting.

> Without patch [1], for reference...
>
> [    0.000000] Kernel command line: console=tty0 selinux=0
> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000

You made a type in the kernel command line, ie. "bebug" should be 
"debug". Anyway, that is not that important for now.

> [    3.952561] mmc0: Invalid maximum block size, assuming 512 bytes
> [    4.010466] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
> using ADMA
> [    4.338545] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
> [    4.347098] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> [    4.350099] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> [    4.378430] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
> [    4.388387] mmc0: new SDIO card at address 0001
> [    4.401773] brcmfmac: F1 signature read @0x18000000=0x9934329
> [    4.407624] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
> F1@0x080ac, err: -84
> [    4.410159] brcmfmac: brcmf_fw_map_chip_to_name: using
> brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
> [    4.781374] brcmfmac mmc0:0001:1: Direct firmware load for
> brcm/brcmfmac4329-sdio.clm_blob failed with error -2
> [    4.781491] brcmfmac mmc0:0001:1: Falling back to user helper
> [   69.601645] brcmfmac: brcmf_c_process_clm_blob: request CLM blob file
> failed (-11)
> [   69.601668] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file
> failed, -11
> [   69.601685] brcmfmac: brcmf_bus_started: failed: -11
> [   69.601728] brcmfmac: brcmf_sdio_firmware_callback: dongle is not
> responding
>
>
> With patch [1]...
>
> [    0.000000] Kernel command line: console=tty0 selinux=0
> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
> [    3.954628] mmc0: Invalid maximum block size, assuming 512 bytes
> [    4.010608] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
> using ADMA
> [    4.341727] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
> [    4.349595] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> [    4.352695] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> [    4.381292] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
> [    4.387377] mmc0: new SDIO card at address 0001
> [    4.399393] brcmfmac: F1 signature read @0x18000000=0x9934329
> [    4.405883] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
> F1@0x080ac, err: -84
> [    4.407207] brcmfmac: brcmf_fw_map_chip_to_name: using
> brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
> [    4.709436] brcmfmac mmc0:0001:1: Direct firmware load for
> brcm/brcmfmac4329-sdio.clm_blob failed with error -2
> [    4.709517] brcmfmac mmc0:0001:1: Falling back to user helper
> [   69.710122] brcmfmac mmc0:0001:1: Direct firmware load for
> brcm/brcmfmac4329-sdio.clm_blob failed with error -2
> [   69.710137] brcmfmac mmc0:0001:1: Falling back to user helper
> [  131.054899] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
> Sep  2 2011 14:48:19 version 4.220.48
> [  131.072561] brcmfmac: brcmf_setup_wiphybands: rxchain error (-23)
> [  131.388384] brcmfmac: _brcmf_set_multicast_list: Setting
> BRCMF_C_SET_PROMISC failed, -23
> [  131.392390] brcmfmac: _brcmf_set_multicast_list: Setting
> BRCMF_C_SET_PROMISC failed, -23
> [  131.920861] brcmfmac: _brcmf_set_multicast_list: Setting
> BRCMF_C_SET_PROMISC failed, -23
> [  131.924183] brcmfmac: _brcmf_set_multicast_list: Setting
> BRCMF_C_SET_PROMISC failed, -23
> [  132.593074] brcmfmac: _brcmf_set_multicast_list: Setting
> BRCMF_C_SET_PROMISC failed, -23
> [  133.135973] brcmfmac: _brcmf_set_multicast_list: Setting
> BRCMF_C_SET_PROMISC failed, -23
> [  133.138223] brcmfmac: _brcmf_set_multicast_list: Setting
> BRCMF_C_SET_PROMISC failed, -23
> [  133.152149] brcmfmac: _brcmf_set_multicast_list: Setting
> BRCMF_C_SET_PROMISC failed, -23
> [  134.311983] brcmfmac: _brcmf_set_multicast_list: Setting
> BRCMF_C_SET_PROMISC failed, -23
> [  134.458577] brcmfmac: _brcmf_set_multicast_list: Setting
> BRCMF_C_SET_PROMISC failed, -23
> [  134.461640] brcmfmac: _brcmf_set_multicast_list: Setting
> BRCMF_C_SET_PROMISC failed, -23
> [  134.555048] brcmfmac: _brcmf_set_multicast_list: Setting
> BRCMF_C_SET_PROMISC failed, -23
>
>
> I can now connect to an AP with the following caveats:
>
> 1) It takes about two minutes before the wlan device is available. For a
> long while I didn't think it was working because I would check dmesg and
> check ifconfig -a before the wlan would be present.

Those two minutes are a direct result of the clm_blob requests. Your 
kernel config has user-mode helper fallback selected, which causes 60 
seconds timeout waiting for user-space to provide the blob. You could 
try and disable it. It is CONFIG_FW_LOADER_USER_HELPER_FALLBACK in your 
.config.

> 2) After reboot I get this nasty error...
> [    0.000000] Kernel command line: console=tty0 selinux=0
> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
> [    2.269750] mmc0: Invalid maximum block size, assuming 512 bytes
> [    2.330010] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
> using ADMA
> [    2.645242] mmc0: error -110 whilst initialising SDIO card

Ok. I suppose you mean a warm reboot. So I suppose the card is not 
properly power cycled. If your SDHCI controller driver (is it 
sdhci-acpi?) is loaded as a module, you could try to unload it and load 
it again. Let me know if that works for you to confirm my guess.

> Regarding the patch, brcmfmac tries to load a firmware file twice for a
> device which the firmware file does not exist. Is there a know list of
> devices which do not need it that we can use to bypass
> brcmf_c_process_clm_blob()?

It is unclear to me why the firmware load is done twice. Could it be in 
the firmware class itself? In brcmfmac there is only one 
request_firmware() call for the clm blob. At least in my version of it. 
Do you have something else?

Regards,
Arend

> Thanks,
> Kyle
>
> On 01/10/2018 03:47 AM, Arend van Spriel wrote:
>> On 1/9/2018 1:51 PM, Kyle Evans wrote:
>>> This is linux-4.15-rc2 on an ASUS TF101. This device was shipped with
>>> Android and a custom kernel using bcmdhd. I have taken nvram.txt from
>>> /system/etc/ on the stock filesystem and copied to
>>> /lib/firmware/brcm/brcmfmac4329-sdio.txt. Below is the result.
>>
>> Ok. So far so good as that nvram.txt is indeed what you want to use.
>>> [    2.729157] brcmfmac: F1 signature read @0x18000000=0x9934329
>>> [    2.734313] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
>>> F1@0x080ac, err: -84
>>
>> The read failure is a bit concerning, but I ignore it for now.
>>
>>> [    2.739952] brcmfmac: brcmf_fw_map_chip_to_name: using
>>> brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
>>> [    2.965820] brcmfmac mmc0:0001:1: Direct firmware load for
>>> brcm/brcmfmac4329-sdio.clm_blob failed with error -2
>>
>> Expected as you did not put a clm_blob file in /lib/firmware/brcm/.
>> However, ...
>>
>>> [    2.969658] brcmfmac mmc0:0001:1: Falling back to user helper
>>> [   64.489695] brcmfmac: brcmf_c_process_clm_blob: request CLM blob file
>>> failed (-11)
>>
>> ...in one of the review cycles for the CLM blob feature it was made
>> clear that this should not result in a probe failure...
>>
>>> [   64.489720] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file
>>> failed, -11
>>> [   64.489739] brcmfmac: brcmf_bus_started: failed: -11
>>
>> ... but it does bail out. Turns out the driver is checking for a
>> specific error code -ENOENT (-2) and not -EAGAIN(-11). A patch has
>> been submitted for it earlier [1], but it was rejected. I have taken
>> another stab at it (see below). Let me know if it works for you.
>>
>>> [   64.489783] brcmfmac: brcmf_sdio_firmware_callback: dongle is not
>>> responding
>>> [   64.596281] [<c061fd98>] (device_release_driver_internal) from
>>> [<c068f394>] (brcmf_sdio_firmware_callback+0x244/0x5b8)
>>> [   64.596500] [<c068f394>] (brcmf_sdio_firmware_callback) from
>>> [<c0686870>] (brcmf_fw_request_nvram_done+0x1cc/0x73c)
>>> [   64.596716] [<c0686870>] (brcmf_fw_request_nvram_done) from
>>> [<c063337c>] (request_firmware_work_func+0x3c/0x64)
>>
>> This stack trace is from a driver bug that has been fixed in later -rc
>> [2].
>>
>> Regards,
>> Arend
>>
>> [1] https://patchwork.kernel.org/patch/10106571/
>> [2] https://patchwork.kernel.org/patch/10075091/
>>
>> ---
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
>> b/driver
>> index 6a59d06..f805600 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
>> @@ -182,12 +182,8 @@ static int brcmf_c_process_clm_blob(struct
>> brcmf_if *ifp)
>>
>>          err = request_firmware(&clm, clm_name, dev);
>>          if (err) {
>> -               if (err == -ENOENT) {
>> -                       brcmf_dbg(INFO, "continue with CLM data
>> currently prese
>> -                       return 0;
>> -               }
>> -               brcmf_err("request CLM blob file failed (%d)\n", err);
>> -               return err;
>> +               brcmf_info("no CLM blob. Firmware may still need it.\n");
>> +               return 0;
>>          }
>>
>>          chunk_buf = kzalloc(sizeof(*chunk_buf) + MAX_CHUNK_LEN - 1,
>> GFP_KERNEL)
>>
Kyle Evans Jan. 16, 2018, 1:20 a.m. UTC | #3
On Sat, Jan 13, 2018 at 10:19:19AM +0100, Arend van Spriel wrote:
> On 1/12/2018 9:18 PM, Kyle Evans wrote:
> > Thank you Arend. I updated to master again, v4.15-rc7+, and applied your
> > patch. All log snips are grabbed with dmesg|grep -E 'mmc0|brcm', as the
> > sdio device is on mmc0.
> 
> Could you follow the reply convention of not top-posting.
> 
> > Without patch [1], for reference...
> >
> > [    0.000000] Kernel command line: console=tty0 selinux=0
> > video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
> 
> You made a type in the kernel command line, ie. "bebug" should be 
> "debug". Anyway, that is not that important for now.
> 
> > [    3.952561] mmc0: Invalid maximum block size, assuming 512 bytes
> > [    4.010466] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
> > using ADMA
> > [    4.338545] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
> > [    4.347098] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> > [    4.350099] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> > [    4.378430] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
> > [    4.388387] mmc0: new SDIO card at address 0001
> > [    4.401773] brcmfmac: F1 signature read @0x18000000=0x9934329
> > [    4.407624] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
> > F1@0x080ac, err: -84
> > [    4.410159] brcmfmac: brcmf_fw_map_chip_to_name: using
> > brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
> > [    4.781374] brcmfmac mmc0:0001:1: Direct firmware load for
> > brcm/brcmfmac4329-sdio.clm_blob failed with error -2
> > [    4.781491] brcmfmac mmc0:0001:1: Falling back to user helper
> > [   69.601645] brcmfmac: brcmf_c_process_clm_blob: request CLM blob file
> > failed (-11)
> > [   69.601668] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file
> > failed, -11
> > [   69.601685] brcmfmac: brcmf_bus_started: failed: -11
> > [   69.601728] brcmfmac: brcmf_sdio_firmware_callback: dongle is not
> > responding
> >
> >
> > With patch [1]...
> >
> > [    0.000000] Kernel command line: console=tty0 selinux=0
> > video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
> > [    3.954628] mmc0: Invalid maximum block size, assuming 512 bytes
> > [    4.010608] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
> > using ADMA
> > [    4.341727] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
> > [    4.349595] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> > [    4.352695] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> > [    4.381292] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
> > [    4.387377] mmc0: new SDIO card at address 0001
> > [    4.399393] brcmfmac: F1 signature read @0x18000000=0x9934329
> > [    4.405883] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
> > F1@0x080ac, err: -84
> > [    4.407207] brcmfmac: brcmf_fw_map_chip_to_name: using
> > brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
> > [    4.709436] brcmfmac mmc0:0001:1: Direct firmware load for
> > brcm/brcmfmac4329-sdio.clm_blob failed with error -2
> > [    4.709517] brcmfmac mmc0:0001:1: Falling back to user helper
> > [   69.710122] brcmfmac mmc0:0001:1: Direct firmware load for
> > brcm/brcmfmac4329-sdio.clm_blob failed with error -2
> > [   69.710137] brcmfmac mmc0:0001:1: Falling back to user helper
> > [  131.054899] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
> > Sep  2 2011 14:48:19 version 4.220.48
> > [  131.072561] brcmfmac: brcmf_setup_wiphybands: rxchain error (-23)
> > [  131.388384] brcmfmac: _brcmf_set_multicast_list: Setting
> > BRCMF_C_SET_PROMISC failed, -23
> > [  131.392390] brcmfmac: _brcmf_set_multicast_list: Setting
> > BRCMF_C_SET_PROMISC failed, -23
> > [  131.920861] brcmfmac: _brcmf_set_multicast_list: Setting
> > BRCMF_C_SET_PROMISC failed, -23
> > [  131.924183] brcmfmac: _brcmf_set_multicast_list: Setting
> > BRCMF_C_SET_PROMISC failed, -23
> > [  132.593074] brcmfmac: _brcmf_set_multicast_list: Setting
> > BRCMF_C_SET_PROMISC failed, -23
> > [  133.135973] brcmfmac: _brcmf_set_multicast_list: Setting
> > BRCMF_C_SET_PROMISC failed, -23
> > [  133.138223] brcmfmac: _brcmf_set_multicast_list: Setting
> > BRCMF_C_SET_PROMISC failed, -23
> > [  133.152149] brcmfmac: _brcmf_set_multicast_list: Setting
> > BRCMF_C_SET_PROMISC failed, -23
> > [  134.311983] brcmfmac: _brcmf_set_multicast_list: Setting
> > BRCMF_C_SET_PROMISC failed, -23
> > [  134.458577] brcmfmac: _brcmf_set_multicast_list: Setting
> > BRCMF_C_SET_PROMISC failed, -23
> > [  134.461640] brcmfmac: _brcmf_set_multicast_list: Setting
> > BRCMF_C_SET_PROMISC failed, -23
> > [  134.555048] brcmfmac: _brcmf_set_multicast_list: Setting
> > BRCMF_C_SET_PROMISC failed, -23
> >
> >
> > I can now connect to an AP with the following caveats:
> >
> > 1) It takes about two minutes before the wlan device is available. For a
> > long while I didn't think it was working because I would check dmesg and
> > check ifconfig -a before the wlan would be present.
> 
> Those two minutes are a direct result of the clm_blob requests. Your 
> kernel config has user-mode helper fallback selected, which causes 60 
> seconds timeout waiting for user-space to provide the blob. You could 
> try and disable it. It is CONFIG_FW_LOADER_USER_HELPER_FALLBACK in your 
> .config.

Yes, it's better without it.

> 
> > 2) After reboot I get this nasty error...
> > [    0.000000] Kernel command line: console=tty0 selinux=0
> > video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
> > [    2.269750] mmc0: Invalid maximum block size, assuming 512 bytes
> > [    2.330010] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
> > using ADMA
> > [    2.645242] mmc0: error -110 whilst initialising SDIO card
> 
> Ok. I suppose you mean a warm reboot. So I suppose the card is not 
> properly power cycled. If your SDHCI controller driver (is it 
> sdhci-acpi?) is loaded as a module, you could try to unload it and load 
> it again. Let me know if that works for you to confirm my guess.

Yes, reboot = warm boot. The driver is sdhci-tegra. I have it built in as 
I am booting without an initrd. I have tried modprobe -r brcmfmac before 
reboot with no difference. It will take some work to create a ramdisk. 

> 
> > Regarding the patch, brcmfmac tries to load a firmware file twice for a
> > device which the firmware file does not exist. Is there a know list of
> > devices which do not need it that we can use to bypass
> > brcmf_c_process_clm_blob()?
> 
> It is unclear to me why the firmware load is done twice. Could it be in 
> the firmware class itself? In brcmfmac there is only one 
> request_firmware() call for the clm blob. At least in my version of it. 
> Do you have something else?

It is your patch [1]. The helper function triggers the while loop. 
However, without the helper function, I do not need the patch.

Helper - patch = return err
No helper - patch = works
Helper + patch = 2m delay
No Helper + patch = works

Now that we've learned that, I suppose this thread can be wrapped up.
I'll start a new thread for the reboot issue in a few days. If you'd
like me to test any new patches, cc me. 

Thanks you for the corrections,
Kyle

> 
> Regards,
> Arend
> 
> > Thanks,
> > Kyle
> >
> > On 01/10/2018 03:47 AM, Arend van Spriel wrote:
> >> On 1/9/2018 1:51 PM, Kyle Evans wrote:
> >>> This is linux-4.15-rc2 on an ASUS TF101. This device was shipped with
> >>> Android and a custom kernel using bcmdhd. I have taken nvram.txt from
> >>> /system/etc/ on the stock filesystem and copied to
> >>> /lib/firmware/brcm/brcmfmac4329-sdio.txt. Below is the result.
> >>
> >> Ok. So far so good as that nvram.txt is indeed what you want to use.
> >>> [    2.729157] brcmfmac: F1 signature read @0x18000000=0x9934329
> >>> [    2.734313] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
> >>> F1@0x080ac, err: -84
> >>
> >> The read failure is a bit concerning, but I ignore it for now.
> >>
> >>> [    2.739952] brcmfmac: brcmf_fw_map_chip_to_name: using
> >>> brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
> >>> [    2.965820] brcmfmac mmc0:0001:1: Direct firmware load for
> >>> brcm/brcmfmac4329-sdio.clm_blob failed with error -2
> >>
> >> Expected as you did not put a clm_blob file in /lib/firmware/brcm/.
> >> However, ...
> >>
> >>> [    2.969658] brcmfmac mmc0:0001:1: Falling back to user helper
> >>> [   64.489695] brcmfmac: brcmf_c_process_clm_blob: request CLM blob file
> >>> failed (-11)
> >>
> >> ...in one of the review cycles for the CLM blob feature it was made
> >> clear that this should not result in a probe failure...
> >>
> >>> [   64.489720] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file
> >>> failed, -11
> >>> [   64.489739] brcmfmac: brcmf_bus_started: failed: -11
> >>
> >> ... but it does bail out. Turns out the driver is checking for a
> >> specific error code -ENOENT (-2) and not -EAGAIN(-11). A patch has
> >> been submitted for it earlier [1], but it was rejected. I have taken
> >> another stab at it (see below). Let me know if it works for you.
> >>
> >>> [   64.489783] brcmfmac: brcmf_sdio_firmware_callback: dongle is not
> >>> responding
> >>> [   64.596281] [<c061fd98>] (device_release_driver_internal) from
> >>> [<c068f394>] (brcmf_sdio_firmware_callback+0x244/0x5b8)
> >>> [   64.596500] [<c068f394>] (brcmf_sdio_firmware_callback) from
> >>> [<c0686870>] (brcmf_fw_request_nvram_done+0x1cc/0x73c)
> >>> [   64.596716] [<c0686870>] (brcmf_fw_request_nvram_done) from
> >>> [<c063337c>] (request_firmware_work_func+0x3c/0x64)
> >>
> >> This stack trace is from a driver bug that has been fixed in later -rc
> >> [2].
> >>
> >> Regards,
> >> Arend
> >>
> >> [1] https://patchwork.kernel.org/patch/10106571/
> >> [2] https://patchwork.kernel.org/patch/10075091/
> >>
> >> ---
> >> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> >> b/driver
> >> index 6a59d06..f805600 100644
> >> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> >> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> >> @@ -182,12 +182,8 @@ static int brcmf_c_process_clm_blob(struct
> >> brcmf_if *ifp)
> >>
> >>          err = request_firmware(&clm, clm_name, dev);
> >>          if (err) {
> >> -               if (err == -ENOENT) {
> >> -                       brcmf_dbg(INFO, "continue with CLM data
> >> currently prese
> >> -                       return 0;
> >> -               }
> >> -               brcmf_err("request CLM blob file failed (%d)\n", err);
> >> -               return err;
> >> +               brcmf_info("no CLM blob. Firmware may still need it.\n");
> >> +               return 0;
> >>          }
> >>
> >>          chunk_buf = kzalloc(sizeof(*chunk_buf) + MAX_CHUNK_LEN - 1,
> >> GFP_KERNEL)
> >>
>
Arend van Spriel Jan. 16, 2018, 8:18 p.m. UTC | #4
On 1/16/2018 2:20 AM, Kyle Evans wrote:
> On Sat, Jan 13, 2018 at 10:19:19AM +0100, Arend van Spriel wrote:
>> On 1/12/2018 9:18 PM, Kyle Evans wrote:
>>> Thank you Arend. I updated to master again, v4.15-rc7+, and applied your
>>> patch. All log snips are grabbed with dmesg|grep -E 'mmc0|brcm', as the
>>> sdio device is on mmc0.
>>
>> Could you follow the reply convention of not top-posting.
>>
>>> Without patch [1], for reference...
>>>
>>> [    0.000000] Kernel command line: console=tty0 selinux=0
>>> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
>>
>> You made a type in the kernel command line, ie. "bebug" should be
>> "debug". Anyway, that is not that important for now.
>>
>>> [    3.952561] mmc0: Invalid maximum block size, assuming 512 bytes
>>> [    4.010466] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
>>> using ADMA
>>> [    4.338545] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
>>> [    4.347098] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
>>> [    4.350099] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
>>> [    4.378430] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
>>> [    4.388387] mmc0: new SDIO card at address 0001
>>> [    4.401773] brcmfmac: F1 signature read @0x18000000=0x9934329
>>> [    4.407624] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
>>> F1@0x080ac, err: -84
>>> [    4.410159] brcmfmac: brcmf_fw_map_chip_to_name: using
>>> brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
>>> [    4.781374] brcmfmac mmc0:0001:1: Direct firmware load for
>>> brcm/brcmfmac4329-sdio.clm_blob failed with error -2
>>> [    4.781491] brcmfmac mmc0:0001:1: Falling back to user helper
>>> [   69.601645] brcmfmac: brcmf_c_process_clm_blob: request CLM blob file
>>> failed (-11)
>>> [   69.601668] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file
>>> failed, -11
>>> [   69.601685] brcmfmac: brcmf_bus_started: failed: -11
>>> [   69.601728] brcmfmac: brcmf_sdio_firmware_callback: dongle is not
>>> responding
>>>
>>>
>>> With patch [1]...
>>>
>>> [    0.000000] Kernel command line: console=tty0 selinux=0
>>> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
>>> [    3.954628] mmc0: Invalid maximum block size, assuming 512 bytes
>>> [    4.010608] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
>>> using ADMA
>>> [    4.341727] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
>>> [    4.349595] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
>>> [    4.352695] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
>>> [    4.381292] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
>>> [    4.387377] mmc0: new SDIO card at address 0001
>>> [    4.399393] brcmfmac: F1 signature read @0x18000000=0x9934329
>>> [    4.405883] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
>>> F1@0x080ac, err: -84
>>> [    4.407207] brcmfmac: brcmf_fw_map_chip_to_name: using
>>> brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
>>> [    4.709436] brcmfmac mmc0:0001:1: Direct firmware load for
>>> brcm/brcmfmac4329-sdio.clm_blob failed with error -2
>>> [    4.709517] brcmfmac mmc0:0001:1: Falling back to user helper
>>> [   69.710122] brcmfmac mmc0:0001:1: Direct firmware load for
>>> brcm/brcmfmac4329-sdio.clm_blob failed with error -2
>>> [   69.710137] brcmfmac mmc0:0001:1: Falling back to user helper
>>> [  131.054899] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>> Sep  2 2011 14:48:19 version 4.220.48
>>> [  131.072561] brcmfmac: brcmf_setup_wiphybands: rxchain error (-23)
>>> [  131.388384] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  131.392390] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  131.920861] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  131.924183] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  132.593074] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  133.135973] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  133.138223] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  133.152149] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  134.311983] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  134.458577] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  134.461640] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  134.555048] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>>
>>>
>>> I can now connect to an AP with the following caveats:
>>>
>>> 1) It takes about two minutes before the wlan device is available. For a
>>> long while I didn't think it was working because I would check dmesg and
>>> check ifconfig -a before the wlan would be present.
>>
>> Those two minutes are a direct result of the clm_blob requests. Your
>> kernel config has user-mode helper fallback selected, which causes 60
>> seconds timeout waiting for user-space to provide the blob. You could
>> try and disable it. It is CONFIG_FW_LOADER_USER_HELPER_FALLBACK in your
>> .config.
>
> Yes, it's better without it.
>
>>
>>> 2) After reboot I get this nasty error...
>>> [    0.000000] Kernel command line: console=tty0 selinux=0
>>> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
>>> [    2.269750] mmc0: Invalid maximum block size, assuming 512 bytes
>>> [    2.330010] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
>>> using ADMA
>>> [    2.645242] mmc0: error -110 whilst initialising SDIO card
>>
>> Ok. I suppose you mean a warm reboot. So I suppose the card is not
>> properly power cycled. If your SDHCI controller driver (is it
>> sdhci-acpi?) is loaded as a module, you could try to unload it and load
>> it again. Let me know if that works for you to confirm my guess.
>
> Yes, reboot = warm boot. The driver is sdhci-tegra. I have it built in as
> I am booting without an initrd. I have tried modprobe -r brcmfmac before
> reboot with no difference. It will take some work to create a ramdisk.
>
>>
>>> Regarding the patch, brcmfmac tries to load a firmware file twice for a
>>> device which the firmware file does not exist. Is there a know list of
>>> devices which do not need it that we can use to bypass
>>> brcmf_c_process_clm_blob()?
>>
>> It is unclear to me why the firmware load is done twice. Could it be in
>> the firmware class itself? In brcmfmac there is only one
>> request_firmware() call for the clm blob. At least in my version of it.
>> Do you have something else?
>
> It is your patch [1]. The helper function triggers the while loop.

That actually is not my patch. I just mentioned that one for reference. 
My patch was at the end of my email message or here [3].

Anyway, Kalle just applied a similar patch [4] which hopefully makes it 
into v4.15 release.

Regards,
Arend

[3] https://patchwork.kernel.org/patch/10154595/
[4] https://patchwork.kernel.org/patch/10166257/
Kyle Evans Jan. 18, 2018, 5:50 p.m. UTC | #5
* Arend van Spriel <arend.vanspriel@broadcom.com>:
> On 1/12/2018 9:18 PM, Kyle Evans wrote:
> > 2) After reboot I get this nasty error...
> > [    0.000000] Kernel command line: console=tty0 selinux=0
> > video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
> > [    2.269750] mmc0: Invalid maximum block size, assuming 512 bytes
> > [    2.330010] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
> > using ADMA
> > [    2.645242] mmc0: error -110 whilst initialising SDIO card
> 
> Ok. I suppose you mean a warm reboot. So I suppose the card is not 
> properly power cycled. If your SDHCI controller driver (is it 
> sdhci-acpi?) is loaded as a module, you could try to unload it and load 
> it again. Let me know if that works for you to confirm my guess.

Your guess is correct. The following brings up wifi after failure to do 
so during warm boot.

modprobe -r sdhci-tegra; modprobe sdhci-tegra;

-Kyle
Arend van Spriel Jan. 19, 2018, 8:21 a.m. UTC | #6
On 1/18/2018 6:50 PM, Kyle Evans wrote:
> * Arend van Spriel <arend.vanspriel@broadcom.com>:
>> On 1/12/2018 9:18 PM, Kyle Evans wrote:
>>> 2) After reboot I get this nasty error...
>>> [    0.000000] Kernel command line: console=tty0 selinux=0
>>> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
>>> [    2.269750] mmc0: Invalid maximum block size, assuming 512 bytes
>>> [    2.330010] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
>>> using ADMA
>>> [    2.645242] mmc0: error -110 whilst initialising SDIO card
>>
>> Ok. I suppose you mean a warm reboot. So I suppose the card is not
>> properly power cycled. If your SDHCI controller driver (is it
>> sdhci-acpi?) is loaded as a module, you could try to unload it and load
>> it again. Let me know if that works for you to confirm my guess.
>
> Your guess is correct. The following brings up wifi after failure to do
> so during warm boot.
>
> modprobe -r sdhci-tegra; modprobe sdhci-tegra;

Do you know if your uses a device tree and where I can find it? 
Typically, there is a GPIO to the wifi device that needs to be toggled 
using mmc powerseq.

Regards,
Arend
Kyle Evans Jan. 19, 2018, 4:05 p.m. UTC | #7
* Arend van Spriel <arend.vanspriel@broadcom.com>:
> On 1/18/2018 6:50 PM, Kyle Evans wrote:
> > * Arend van Spriel <arend.vanspriel@broadcom.com>:
> >> On 1/12/2018 9:18 PM, Kyle Evans wrote:
> >>> 2) After reboot I get this nasty error...
> >>> [    0.000000] Kernel command line: console=tty0 selinux=0
> >>> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
> >>> [    2.269750] mmc0: Invalid maximum block size, assuming 512 bytes
> >>> [    2.330010] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
> >>> using ADMA
> >>> [    2.645242] mmc0: error -110 whilst initialising SDIO card
> >>
> >> Ok. I suppose you mean a warm reboot. So I suppose the card is not
> >> properly power cycled. If your SDHCI controller driver (is it
> >> sdhci-acpi?) is loaded as a module, you could try to unload it and load
> >> it again. Let me know if that works for you to confirm my guess.
> >
> > Your guess is correct. The following brings up wifi after failure to do
> > so during warm boot.
> >
> > modprobe -r sdhci-tegra; modprobe sdhci-tegra;
> 
> Do you know if your uses a device tree and where I can find it? 
> Typically, there is a GPIO to the wifi device that needs to be toggled 
> using mmc powerseq.

I had a hunch this is was the next step. This device did not ship with a 
DT, but I have one in the works. My initial trial & error has been met 
with error. 

This is what I have so far, which is wrong since adding pwrseq (boot panic):
	sdhci@c8000000 {
                compatible = "nvidia,tegra20-sdhci";
                reg = <0xc8000000 0x200>;
                interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
                clocks = <&tegra_car TEGRA20_CLK_SDMMC1>;
                resets = <&tegra_car 14>;
                reset-names = "sdhci";

                status = "okay";
                //power-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
                bus-width = <4>;
                keep-power-in-suspend;
                non-removable;
                mmc-pwrseq = <&wlan_rst>;

                brcmf: wifi@1 {
                        compatible = "brcm,bcm4329-fmac";
                        interrupt-parent = <&gpio>;
                        interrupts = <TEGRA_GPIO(Y, 6) GPIO_ACTIVE_HIGH>,
                                     <TEGRA_GPIO(S, 0) GPIO_ACTIVE_HIGH>;
                        interrupt-names = "host-wake";
                };
        };

        wlan_rst: sdhci0_pwrseq {
                compatible = "mmc-pwrseq-simple";
                reset-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_LOW>;
        };


This stuff is from a pre-DT kernel:

#define TF101_WLAN_RST  TEGRA_GPIO_PK6
#define TF101_WLAN_WOW  TEGRA_GPIO_PS0
#define TF101_SDIO_WOW  TEGRA_GPIO_PY6

static struct embedded_sdio_data embedded_sdio_data1 = {
        .cccr   = {
                .sdio_vsn       = 2,
                .multi_block    = 1,
                .low_speed      = 0,
                .wide_bus       = 0,
                .high_power     = 1,
                .high_speed     = 1,
        },
        .cis  = {
                .vendor         = 0x02d0,
                .device         = 0x4329,
        },
}
static struct tegra_sdhci_platform_data tegra_sdhci_platform_data1 = {
        .mmc_data = {
                .register_status_notify = tf101_wifi_status_register,
                .embedded_sdio = &embedded_sdio_data1,
                .built_in = 0,
        },
        .wow_gpio = TF101_SDIO_WOW,
        .cd_gpio = -1,
        .wp_gpio = -1,
        .power_gpio = -1,
        .max_clk_limit = 40000000,
}

static int tf101_wifi_power(int on)
{
        pr_debug("%s: %d\n", __func__, on);

#if 0
        gpio_set_value(TF101_WLAN_PWR, on);
        mdelay(100);
#endif
        gpio_set_value(TF101_WLAN_RST, on);
        mdelay(200);

        return 0;
}

static int __init tf101_wifi_init(void)
{
        //gpio_request(TF101_WLAN_PWR, "wlan_power");
        gpio_request(TF101_WLAN_RST, "wlan_rst");
        gpio_request(TF101_WLAN_WOW, "bcmsdh_sdmmc");

        //tegra_gpio_enable(TF101_WLAN_PWR);
        tegra_gpio_enable(TF101_WLAN_RST);
        tegra_gpio_enable(TF101_WLAN_WOW);

        //gpio_direction_output(TF101_WLAN_PWR, 0);
        gpio_direction_output(TF101_WLAN_RST, 0);
        gpio_direction_input(TF101_WLAN_WOW);

        platform_device_register(&tf101_wifi_device);

        device_init_wakeup(&tf101_wifi_device.dev, 1);
        device_set_wakeup_enable(&tf101_wifi_device.dev, 0);

        return 0;
}

static struct resource tf101_bcm4329_rfkill_resources[] = {
        {
                .name   = "bcm4329_nshutdown_gpio",
                .start  = TEGRA_GPIO_PU0,
                .end    = TEGRA_GPIO_PU0,
                .flags  = IORESOURCE_IO,
        },
};

static struct resource tf101_bluesleep_resources[] = {
        [0] = {
                .name = "gpio_host_wake",
                        .start  = TEGRA_GPIO_PU6,
                        .end    = TEGRA_GPIO_PU6,
                        .flags  = IORESOURCE_IO,
        },
        [1] = {
                .name = "gpio_ext_wake",
                        .start  = TEGRA_GPIO_PU1,
                        .end    = TEGRA_GPIO_PU1,
                        .flags  = IORESOURCE_IO,
        },
        [2] = {
                .name = "host_wake",
                        .start  = TEGRA_GPIO_TO_IRQ(TEGRA_GPIO_PU6),
                        .end    = TEGRA_GPIO_TO_IRQ(TEGRA_GPIO_PU6),
                        .flags  = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE,
        },
};

Asside from getting reboot to work, I am at a loss where to put all of 
the wakeup sources and rfkill nodes.
S,0 - WLAN_WOW
Y,6 - SDIO_WOW
U,6 - bt host_wake
U,1 - bt ext_wake
U,0 - rfkill

Thanks,
Kyle

> 
> Regards,
> Arend
>
Arend van Spriel Jan. 22, 2018, 9:22 a.m. UTC | #8
On 1/19/2018 5:05 PM, Kyle Evans wrote:
> * Arend van Spriel <arend.vanspriel@broadcom.com>:
>> On 1/18/2018 6:50 PM, Kyle Evans wrote:
>>> * Arend van Spriel <arend.vanspriel@broadcom.com>:
>>>> On 1/12/2018 9:18 PM, Kyle Evans wrote:
>>>>> 2) After reboot I get this nasty error...
>>>>> [    0.000000] Kernel command line: console=tty0 selinux=0
>>>>> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
>>>>> [    2.269750] mmc0: Invalid maximum block size, assuming 512 bytes
>>>>> [    2.330010] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
>>>>> using ADMA
>>>>> [    2.645242] mmc0: error -110 whilst initialising SDIO card
>>>>
>>>> Ok. I suppose you mean a warm reboot. So I suppose the card is not
>>>> properly power cycled. If your SDHCI controller driver (is it
>>>> sdhci-acpi?) is loaded as a module, you could try to unload it and load
>>>> it again. Let me know if that works for you to confirm my guess.
>>>
>>> Your guess is correct. The following brings up wifi after failure to do
>>> so during warm boot.
>>>
>>> modprobe -r sdhci-tegra; modprobe sdhci-tegra;
>>
>> Do you know if your uses a device tree and where I can find it?
>> Typically, there is a GPIO to the wifi device that needs to be toggled
>> using mmc powerseq.
>
> I had a hunch this is was the next step. This device did not ship with a
> DT, but I have one in the works. My initial trial & error has been met
> with error.

So I am getting predictable huh?

> This is what I have so far, which is wrong since adding pwrseq (boot panic):
> 	sdhci@c8000000 {
>                  compatible = "nvidia,tegra20-sdhci";
>                  reg = <0xc8000000 0x200>;
>                  interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
>                  clocks = <&tegra_car TEGRA20_CLK_SDMMC1>;
>                  resets = <&tegra_car 14>;
>                  reset-names = "sdhci";
>
>                  status = "okay";
>                  //power-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
>                  bus-width = <4>;
>                  keep-power-in-suspend;
>                  non-removable;
>                  mmc-pwrseq = <&wlan_rst>;
>
>                  brcmf: wifi@1 {
>                          compatible = "brcm,bcm4329-fmac";
>                          interrupt-parent = <&gpio>;
>                          interrupts = <TEGRA_GPIO(Y, 6) GPIO_ACTIVE_HIGH>,
>                                       <TEGRA_GPIO(S, 0) GPIO_ACTIVE_HIGH>;
>                          interrupt-names = "host-wake";

Always having a hard time reading this stuff. So does interrupts 
property state 2 interrupts here? If so, than interrupt-names should 
also have two names. Actually, according to the binding only a single 
interrupt should be given (only (S, 0) I think). Furthermore, you are 
missing the 'reg' property to specify the SDIO function, ie. "reg = <1>;".

>                  };
>          };
>
>          wlan_rst: sdhci0_pwrseq {
>                  compatible = "mmc-pwrseq-simple";
>                  reset-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_LOW>;
>          };

Ignoring the ext_clk stuff, the pwrseq-simple does following: upon power 
on, set reset-gpios to 1, power on bus, set reset-gpios back to 0, 
optionally wait for post_power_on_delay_ms. The pre-DT kernel stuff is 
different. It simply sets the reset gpio to 1 upon power on, and wait 
for 200ms leaving the gpio as is and does the same for power off.

TF101_SDIO_WOW seems for enabling host wakeup by the host-controller 
device for which I would expect the driver to call device_init_wakeup(). 
However, this functionality does not seem present in the sdhci-tegra driver.

Regards,
Arend
Kyle Evans Jan. 26, 2018, 10:45 a.m. UTC | #9
* Arend van Spriel <arend.vanspriel@broadcom.com>:
> On 1/19/2018 5:05 PM, Kyle Evans wrote:
> > * Arend van Spriel <arend.vanspriel@broadcom.com>:
> >> On 1/18/2018 6:50 PM, Kyle Evans wrote:
> >>> * Arend van Spriel <arend.vanspriel@broadcom.com>:
> >>>> On 1/12/2018 9:18 PM, Kyle Evans wrote:
> >>>>> 2) After reboot I get this nasty error...
> >>>>> [    0.000000] Kernel command line: console=tty0 selinux=0
> >>>>> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
> >>>>> [    2.269750] mmc0: Invalid maximum block size, assuming 512 bytes
> >>>>> [    2.330010] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
> >>>>> using ADMA
> >>>>> [    2.645242] mmc0: error -110 whilst initialising SDIO card
> >>>>
> >>>> Ok. I suppose you mean a warm reboot. So I suppose the card is not
> >>>> properly power cycled. If your SDHCI controller driver (is it
> >>>> sdhci-acpi?) is loaded as a module, you could try to unload it and load
> >>>> it again. Let me know if that works for you to confirm my guess.
> >>>
> >>> Your guess is correct. The following brings up wifi after failure to do
> >>> so during warm boot.
> >>>
> >>> modprobe -r sdhci-tegra; modprobe sdhci-tegra;
> >>
> >> Do you know if your uses a device tree and where I can find it?
> >> Typically, there is a GPIO to the wifi device that needs to be toggled
> >> using mmc powerseq.
> >
> > I had a hunch this is was the next step. This device did not ship with a
> > DT, but I have one in the works. My initial trial & error has been met
> > with error.
> 
> So I am getting predictable huh?

> 
> > This is what I have so far, which is wrong since adding pwrseq (boot panic):
> > 	sdhci@c8000000 {
> >                  compatible = "nvidia,tegra20-sdhci";
> >                  reg = <0xc8000000 0x200>;
> >                  interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
> >                  clocks = <&tegra_car TEGRA20_CLK_SDMMC1>;
> >                  resets = <&tegra_car 14>;
> >                  reset-names = "sdhci";
> >
> >                  status = "okay";
> >                  //power-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
> >                  bus-width = <4>;
> >                  keep-power-in-suspend;
> >                  non-removable;
> >                  mmc-pwrseq = <&wlan_rst>;
> >
> >                  brcmf: wifi@1 {
> >                          compatible = "brcm,bcm4329-fmac";
> >                          interrupt-parent = <&gpio>;
> >                          interrupts = <TEGRA_GPIO(Y, 6) GPIO_ACTIVE_HIGH>,
> >                                       <TEGRA_GPIO(S, 0) GPIO_ACTIVE_HIGH>;
> >                          interrupt-names = "host-wake";
> 
> Always having a hard time reading this stuff. So does interrupts 
> property state 2 interrupts here?

Ok, I've slimmed it down to only S,0-"host-wake".

> If so, than interrupt-names should 
> also have two names. Actually, according to the binding only a single 
> interrupt should be given (only (S, 0) I think). Furthermore, you are 
> missing the 'reg' property to specify the SDIO function, ie. "reg = <1>;".

I took the reg property out becuase it causes the below compiler
warnings. Putting it back in causes a black screen with no console
output. Any clues?

arch/arm/boot/dts/tegra20-tf101.dtb: Warning (reg_format): "reg"
property in /sdhci@c8000000/wifi@1 has invalid length (4 bytes)
(#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/tegra20-tf101.dtb: Warning (avoid_default_addr_size):
Relying on default #address-cells value for /sdhci@c8000000/wifi@1
arch/arm/boot/dts/tegra20-tf101.dtb: Warning (avoid_default_addr_size):
Relying on default #size-cells value for /sdhci@c8000000/wifi@1

> 
> >                  };
> >          };
> >
> >          wlan_rst: sdhci0_pwrseq {
> >                  compatible = "mmc-pwrseq-simple";
> >                  reset-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_LOW>;
> >          };
> 
> Ignoring the ext_clk stuff, the pwrseq-simple does following: upon power 
> on, set reset-gpios to 1, power on bus, set reset-gpios back to 0, 
> optionally wait for post_power_on_delay_ms. The pre-DT kernel stuff is 
> different. It simply sets the reset gpio to 1 upon power on, and wait 
> for 200ms leaving the gpio as is and does the same for power off.

So,,,, pwrseq is the wrong approach here?

	wlan_rst: sdhci0_pwrseq {
                compatible = "mmc-pwrseq-simple";
                reset-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
                //post-power-on-delay-ms = <200>;
                post-power-off-delay-us = <200>;
        };

I have tested with/without ACTIVE_LOW/HIGH, on/off-delay, all combinations. 
Using ACTIVE_HIGH, which is contrary to binding documentation, allows the sdhci
controller to enumerate. It does not enumerate with ACTIVE_LOW. no
combination loads brcmfmac.

I did the same with U,0, which is the rfkill resource, moving K,6 back to
power-gpios. This got me back to square one, works on cold boot only,
with any combination.

It is indicated that power off is were the problem is. On the other 
hand, it would seem that there should be a reset mechanism and we 
either have the wrong pin, or it is not being triggered properly.

> 
> TF101_SDIO_WOW seems for enabling host wakeup by the host-controller 
> device for which I would expect the driver to call device_init_wakeup(). 
> However, this functionality does not seem present in the sdhci-tegra driver.

I think I follow, is this in-band IRQ related?
I just don't understand what the host controller has to do with wireless wakeup,
since the wireless is part of a doughter card. Unless they both need to be
enabled for WOW to work. At any rate, WOW is of little importance at this time.
I was just curious where to put all of the pieces and it looks like
there is no room for all of the pieces.

-Kyle

> 
> Regards,
> Arend
diff mbox

Patch

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
b/driver
index 6a59d06..f805600 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -182,12 +182,8 @@  static int brcmf_c_process_clm_blob(struct brcmf_if 
*ifp)

         err = request_firmware(&clm, clm_name, dev);
         if (err) {
-               if (err == -ENOENT) {
-                       brcmf_dbg(INFO, "continue with CLM data 
currently prese
-                       return 0;
-               }
-               brcmf_err("request CLM blob file failed (%d)\n", err);
-               return err;
+               brcmf_info("no CLM blob. Firmware may still need it.\n");
+               return 0;
         }