commit 09cedbd upstream.

pwseq_sd8787 could also be used with wilc1000_sdio driver. Add
a dependency for this.

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20210820092803.78523-4-claudiu.beznea@microchip.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lukas Wunner <lukas@wunner.de>

commit 18b8460 upstream.

pwrseq_sd8787 is forced to be built as a module if its dependencies are.

That's unnecessary, it's perfectly fine for it to be built-in even
though the wireless drivers that need it are modules.

Relax the depends definition in Kconfig accordingly.

Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Matt Ranostay <matt@ranostay.consulting>
Cc: Lubomir Rintel <lkundrak@v3.sk>
Cc: Claudiu Beznea <claudiu.beznea@microchip.com>

commit raspberrypi/linux@5a16077 upstream.

bcm2835_mmc_probe() ignores errors returned by mmc_of_parse() and in
particular ignores -EPROBE_DEFER, which may be returned if the power
sequencing driver configured in the devicetree is compiled as a module.

The user-visible result is that access to the SDIO device fails because
its power sequencing requirements have not been observed.  Fix it.

Signed-off-by: Lukas Wunner <lukas@wunner.de>

commit 255ca28 upstream.

Some WiFi/Bluetooth modules might have different host connection
options, allowing to either use SDIO for both WiFi and Bluetooth,
or SDIO for WiFi and UART for Bluetooth. It is possible to detect
whether a module has SDIO-SDIO or SDIO-UART connection by reading
its host strap register.

This change introduces a way to automatically select appropriate
firmware depending of the connection method, and removes a need
of symlinking or overwriting the original firmware file with a
required one.

Host strap register used in this commit comes from the NXP driver [1]
hosted at Code Aurora.

[1] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/net/wireless/nxp/mxm_wifiex/wlan_src/mlinux/moal_sdio_mmc.c?h=rel_imx_5.4.70_2.3.2&id=688b67b2c7220b01521ffe560da7eee33042c7bd#n1274

Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220422090313.125857-2-andrejs.cainikovs@toradex.com
Signed-off-by: Lukas Wunner <lukas@wunner.de>

commit 36dd7a4 upstream.

Commit e3fffc1 ("devicetree: document new marvell-8xxx and
pwrseq-sd8787 options") documented a compatible string for SD8787 in
the devicetree bindings, but neglected to add it to the mwifiex driver.

Fixes: e3fffc1 ("devicetree: document new marvell-8xxx and pwrseq-sd8787 options")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v4.11+
Cc: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/320de5005ff3b8fd76be2d2b859fd021689c3681.1674827105.git.lukas@wunner.de

commit bba047f upstream.

The Marvell SD8978 (aka NXP IW416) uses identical registers as SD8987,
so reuse the existing mwifiex_reg_sd8987 definition.

Note that mwifiex_reg_sd8977 and mwifiex_reg_sd8997 are likewise
identical, save for the fw_dump_ctrl register:  They define it as 0xf0
whereas mwifiex_reg_sd8987 defines it as 0xf9.  I've verified that
0xf9 is the correct value on SD8978.  NXP's out-of-tree driver uses
0xf9 for all of them, so there's a chance that 0xf0 is not correct
in the mwifiex_reg_sd8977 and mwifiex_reg_sd8997 definitions.  I cannot
test that for lack of hardware, hence am leaving it as is.

NXP has only released a firmware which runs Bluetooth over UART.
Perhaps Bluetooth over SDIO is unsupported by this chipset.
Consequently, only an "sdiouart" firmware image is referenced, not an
alternative "sdsd" image.

Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/536b4f17a72ca460ad1b07045757043fb0778988.1674827105.git.lukas@wunner.de

commit 7715d79 upstream.

Support the firmware hotfix version in GET_HW_SPEC responses to avoid an
irritating "Unknown api_id: 5" message on probe.

Based on this commit in NXP's GPLv2-licensed out-of-tree driver:
nxp-imx/mwifiex@27fd8ecca504

Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Sherry Sun <sherry.sun@nxp.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/111c7ee895f12d951e95a2edcd06d87ca26a7d0f.1674827105.git.lukas@wunner.de

pwrseq_sd8787 allows proper handling of Reset and Powerdown GPIOs for
the Maya WiFi module which is built into RevPi Flat S 2022.

So enable that driver in all relevant configs.

Signed-off-by: Lukas Wunner <lukas@wunner.de>

We've just amended the mwifiex mainline driver to support IW416,
the chipset on which Maya WiFi modules are based.

So use the mainline driver instead of NXP's out-of-tree driver in the
RevPi Flat S 2022 devicetree overlay.

While at it, take advantage of the existing SD8787 power sequencing
driver in the mainline kernel.

Signed-off-by: Lukas Wunner <lukas@wunner.de>