sdhci: tegra: Add workaround for Broadcom WiFi

All Tegra20 boards that have embedded Broadcom WiFi SDIO chip are affected by a problem where WiFi chip reports CCCR v1.10, while it should v1.20. In a result high-speed mode isn't enabled for the WiFi card and this results in a malfunctioning SDIO communication.

brcmfmac: brcmf_sdio_readframes: read 304 bytes from channel 1 failed: -84
brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK

Downstream kernels are overriding card's CCCR info in SDHCI driver to fix the problem, let's do the same in upstream.

The change is inspired by omap_hsmmc_init_card() of OMAP's HSMMC driver, which overrides card's info for the TI wl1251 WiFi.

Signed-off-by Dmitry Osipenko <[email protected]>

---
 drivers/mmc/host/sdhci-tegra.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

drivers/mmc/host/sdhci-tegra.c +28 -0

index 7bc950520fd9..2ad87da98f2c 100644
@@ -1501,6 +1501,32 @@ static int sdhci_tegra_add_host(struct sdhci_host *host)
 	return ret;
 }
 
+static void sdhci_tegra_init_card(struct mmc_host *mmc, struct mmc_card *card)
+{
+	if (card->type == MMC_TYPE_SDIO) {
+		struct device_node *np = mmc_dev(mmc)->of_node;
+
+		np = of_get_compatible_child(np, "brcm,bcm4329-fmac");
+		if (np) {
+			dev_info(mmc_dev(mmc), "found bcm4329\n");
+
+			/*
+			 * All Tegra20 boards that have embedded BCM4329
+			 * chip need to enable high speed for SDIO, otherwise
+			 * further communication with the card doesn't work
+			 * well.
+			 *
+			 * Later BCM43xx chips do not need this workaround,
+			 * but there is no good way to differentiate chip's
+			 * version at this stage and it doesn't cause any
+			 * harm for the later chips.
+			 */
+			card->cccr.high_speed = 1;
+			of_node_put(np);
+		}
+	}
+}
+
 static int sdhci_tegra_probe(struct platform_device *pdev)
 {
 	const struct of_device_id *match;

@@ -1545,6 +1571,8 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
 		host->mmc_host_ops.execute_tuning =
 				tegra_sdhci_execute_hw_tuning;
 
+	host->mmc_host_ops.init_card = sdhci_tegra_init_card;
+
 	rc = mmc_of_parse(host->mmc);
 	if (rc)
 		goto err_parse_dt;

Signature · 1 line

2.24.0

Quoted 11 lines

All Tegra20 boards that have embedded Broadcom WiFi SDIO chip are affected by a problem where WiFi chip reports CCCR v1.10, while it should v1.20. In a result high-speed mode isn't enabled for the WiFi card and this results in a malfunctioning SDIO communication.

brcmfmac: brcmf_sdio_readframes: read 304 bytes from channel 1 failed: -84
brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK

Downstream kernels are overriding card's CCCR info in SDHCI driver to fix the problem, let's do the same in upstream.

Quoted 7 lines

The change is inspired by omap_hsmmc_init_card() of OMAP's HSMMC driver, which overrides card's info for the TI wl1251 WiFi.

Signed-off-by Dmitry Osipenko <[email protected]>

---
 drivers/mmc/host/sdhci-tegra.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

This seems like the wrong place to do this. If this is specific to this WiFi SDIO chip this should be handled at the SDIO card or function level. It seems like the SDIO infrastructure doesn't currently allow this because the OF nodes are attached to the card after mmc_sdio_init_card(), whereas it seems like the quirk is already needed during mmc_sdio_init_card().

That said, I think we could have some common code that's executed as part of mmc_attach_sdio() (and before mmc_sdio_init_card()).

Actually, it looks like we already have something like that. mmc_sdio_init_card() calls mmc_fixup_device() with sdio_fixup_methods after doing some very basic initialization. Do you know if things start to go wrong before or after that point? It might be worth looking at that SDIO fixup array and add something that would override the CCCR support. That would fix things in a more generic way rather than requiring every host controller driver to duplicate this quirk.

10.12.2019 15:52, Thierry Reding пишет:

Quoted 30 lines · Dmitry Osipenko

Quoted 11 lines

All Tegra20 boards that have embedded Broadcom WiFi SDIO chip are affected by a problem where WiFi chip reports CCCR v1.10, while it should v1.20. In a result high-speed mode isn't enabled for the WiFi card and this results in a malfunctioning SDIO communication.

brcmfmac: brcmf_sdio_readframes: read 304 bytes from channel 1 failed: -84
brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK

Downstream kernels are overriding card's CCCR info in SDHCI driver to fix the problem, let's do the same in upstream.

Quoted 7 lines

The change is inspired by omap_hsmmc_init_card() of OMAP's HSMMC driver, which overrides card's info for the TI wl1251 WiFi.

Signed-off-by Dmitry Osipenko <[email protected]>

---
 drivers/mmc/host/sdhci-tegra.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

This seems like the wrong place to do this. If this is specific to this WiFi SDIO chip this should be handled at the SDIO card or function level. It seems like the SDIO infrastructure doesn't currently allow this because the OF nodes are attached to the card after mmc_sdio_init_card(), whereas it seems like the quirk is already needed during mmc_sdio_init_card().

That said, I think we could have some common code that's executed as part of mmc_attach_sdio() (and before mmc_sdio_init_card()).

Quoted 7 lines

Actually, it looks like we already have something like that. mmc_sdio_init_card() calls mmc_fixup_device() with sdio_fixup_methods after doing some very basic initialization. Do you know if things start to go wrong before or after that point? It might be worth looking at that SDIO fixup array and add something that would override the CCCR support. That would fix things in a more generic way rather than requiring every host controller driver to duplicate this quirk.

Hello Thierry,

Thank you very much for the suggestion, looks like indeed it is possible to make workaround in a generic way.

Ulf / Adrian, will something like this be acceptable:

drivers/mmc/core/card.h +6 -0

index 7bd392d55cfa..a6001f210b9e 100644
@@ -150,6 +150,12 @@ static inline void __maybe_unused
 add_limit_rate_quirk(struct mmc_card *card,
 	card->quirk_max_rate = data;
 }
 
+static inline void __maybe_unused add_high_speed_quirk(struct mmc_card
 *card,
+						       int data)
+{
+	card->cccr.high_speed = data;
+}
+
 /*

* Quirk add/remove for MMC products.
*/

drivers/mmc/core/quirks.h +0 -0

index 3dba15bccce2..a824c0caa7fb 100644

10.12.2019 15:52, Thierry Reding пишет:

Quoted 30 lines · Dmitry Osipenko

Quoted 11 lines

All Tegra20 boards that have embedded Broadcom WiFi SDIO chip are affected by a problem where WiFi chip reports CCCR v1.10, while it should v1.20. In a result high-speed mode isn't enabled for the WiFi card and this results in a malfunctioning SDIO communication.

brcmfmac: brcmf_sdio_readframes: read 304 bytes from channel 1 failed: -84
brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK

Downstream kernels are overriding card's CCCR info in SDHCI driver to fix the problem, let's do the same in upstream.

Quoted 7 lines

The change is inspired by omap_hsmmc_init_card() of OMAP's HSMMC driver, which overrides card's info for the TI wl1251 WiFi.

Signed-off-by Dmitry Osipenko <[email protected]>

---
 drivers/mmc/host/sdhci-tegra.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

This seems like the wrong place to do this. If this is specific to this WiFi SDIO chip this should be handled at the SDIO card or function level. It seems like the SDIO infrastructure doesn't currently allow this because the OF nodes are attached to the card after mmc_sdio_init_card(), whereas it seems like the quirk is already needed during mmc_sdio_init_card().

That said, I think we could have some common code that's executed as part of mmc_attach_sdio() (and before mmc_sdio_init_card()).

Quoted 7 lines

Actually, it looks like we already have something like that. mmc_sdio_init_card() calls mmc_fixup_device() with sdio_fixup_methods after doing some very basic initialization. Do you know if things start to go wrong before or after that point? It might be worth looking at that SDIO fixup array and add something that would override the CCCR support. That would fix things in a more generic way rather than requiring every host controller driver to duplicate this quirk.

Hello Thierry,

Thank you very much for the suggestion, looks like indeed it is possible to make workaround in a generic way.

Ulf / Adrian, will something like this be acceptable:

drivers/mmc/core/card.h +6 -0

index 7bd392d55cfa..a6001f210b9e 100644
@@ -150,6 +150,12 @@ static inline void __maybe_unused
 add_limit_rate_quirk(struct mmc_card *card,
 	card->quirk_max_rate = data;
 }
 
+static inline void __maybe_unused add_high_speed_quirk(struct mmc_card
 *card,
+						       int data)
+{
+	card->cccr.high_speed = data;
+}
+
 /*

* Quirk add/remove for MMC products.
*/

drivers/mmc/core/quirks.h +0 -0

index 3dba15bccce2..a824c0caa7fb 100644

All Tegra20 boards that have embedded Broadcom WiFi SDIO chip are affected by a problem where WiFi chip reports CCCR v1.10, while it should v1.20. In a result high-speed mode isn't enabled for the WiFi card and this results in a malfunctioning SDIO communication.

brcmfmac: brcmf_sdio_readframes: read 304 bytes from channel 1 failed: -84
brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK

Downstream kernels are overriding card's CCCR info in SDHCI driver to fix the problem, let's do the same in upstream.

The change is inspired by omap_hsmmc_init_card() of OMAP's HSMMC driver, which overrides card's info for the TI wl1251 WiFi.

Signed-off-by Dmitry Osipenko <[email protected]>

---
 drivers/mmc/host/sdhci-tegra.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

drivers/mmc/host/sdhci-tegra.c +28 -1

index 7bc950520fd9..2ad87da98f2c 100644
@@ -1501,6 +1501,32 @@ static int sdhci_tegra_add_host(struct sdhci_host *host)
        return ret;
 }
 
+static void sdhci_tegra_init_card(struct mmc_host *mmc, struct mmc_card *card)
+{
+       if (card->type == MMC_TYPE_SDIO) {
+               struct device_node *np = mmc_dev(mmc)->of_node;
+
+               np = of_get_compatible_child(np, "brcm,bcm4329-fmac");
+               if (np) {
+                       dev_info(mmc_dev(mmc), "found bcm4329\n");
+
+                       /*
+                        * All Tegra20 boards that have embedded BCM4329
+                        * chip need to enable high speed for SDIO, otherwise
+                        * further communication with the card doesn't work
+                        * well.
+                        *
+                        * Later BCM43xx chips do not need this workaround,
+                        * but there is no good way to differentiate chip's
+                        * version at this stage and it doesn't cause any
+                        * harm for the later chips.
+                        */
+                       card->cccr.high_speed = 1;
+                       of_node_put(np);
+               }
+       }
+}
+
 static int sdhci_tegra_probe(struct platform_device *pdev)
 {
        const struct of_device_id *match;

@@ -1545,6 +1571,8 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
                host->mmc_host_ops.execute_tuning =
                                tegra_sdhci_execute_hw_tuning;
 
+       host->mmc_host_ops.init_card = sdhci_tegra_init_card;
+
        rc = mmc_of_parse(host->mmc);
        if (rc)
                goto err_parse_dt;
--

2.24.0

Quoted 5 lines

All Tegra20 boards that have embedded Broadcom WiFi SDIO chip are affected by a problem where WiFi chip reports CCCR v1.10, while it should v1.20. In a result high-speed mode isn't enabled for the WiFi card and this results in a malfunctioning SDIO communication.

Does that also mean SDIO_SPEED_SHS bit is set when reading SDIO_CCCR_SPEED?

Quoted 8 lines

brcmfmac: brcmf_sdio_readframes: read 304 bytes from channel 1 failed: -84
brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK

Downstream kernels are overriding card's CCCR info in SDHCI driver to fix the problem, let's do the same in upstream.

The change is inspired by omap_hsmmc_init_card() of OMAP's HSMMC driver, which overrides card's info for the TI wl1251 WiFi.

This is a temporary solution and should be replaced by doing the DT parsing during

So, yes, let's see if we can use a card quirk instead. That's the first option.

A second option is simply to parse the DT subnode for a new DT property during mmc_sdio_init_card(). Along the lines of what we do for the broken-hpi DT binding for eMMC.

Hello Ulf,

11.12.2019 11:11, Ulf Hansson пишет:

Quoted 8 lines · Dmitry Osipenko

Quoted 5 lines

All Tegra20 boards that have embedded Broadcom WiFi SDIO chip are affected by a problem where WiFi chip reports CCCR v1.10, while it should v1.20. In a result high-speed mode isn't enabled for the WiFi card and this results in a malfunctioning SDIO communication.

Does that also mean SDIO_SPEED_SHS bit is set when reading SDIO_CCCR_SPEED?

Yes, the SDIO_SPEED_SHS bit is set.

Quoted 14 lines

Quoted 8 lines

brcmfmac: brcmf_sdio_readframes: read 304 bytes from channel 1 failed: -84
brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK

Downstream kernels are overriding card's CCCR info in SDHCI driver to fix the problem, let's do the same in upstream.

The change is inspired by omap_hsmmc_init_card() of OMAP's HSMMC driver, which overrides card's info for the TI wl1251 WiFi.

This is a temporary solution and should be replaced by doing the DT parsing during

So, yes, let's see if we can use a card quirk instead. That's the first option.

Quoted 3 lines

A second option is simply to parse the DT subnode for a new DT property during mmc_sdio_init_card(). Along the lines of what we do for the broken-hpi DT binding for eMMC.

Let's try the first option. My understanding is that the problem affects only the specific model of the WiFi chip and it's not a board-specific problem. I'll add Broadcom driver people to CC for the next version of the patch, maybe they'll have something to say.

Quoted 29 lines

Hello Ulf,

11.12.2019 11:11, Ulf Hansson пишет:

Quoted 8 lines · Dmitry Osipenko

Quoted 5 lines

All Tegra20 boards that have embedded Broadcom WiFi SDIO chip are affected by a problem where WiFi chip reports CCCR v1.10, while it should v1.20. In a result high-speed mode isn't enabled for the WiFi card and this results in a malfunctioning SDIO communication.

Does that also mean SDIO_SPEED_SHS bit is set when reading SDIO_CCCR_SPEED?

Yes, the SDIO_SPEED_SHS bit is set.

Quoted 14 lines

Quoted 8 lines

brcmfmac: brcmf_sdio_readframes: read 304 bytes from channel 1 failed: -84
brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK

Downstream kernels are overriding card's CCCR info in SDHCI driver to fix the problem, let's do the same in upstream.

The change is inspired by omap_hsmmc_init_card() of OMAP's HSMMC driver, which overrides card's info for the TI wl1251 WiFi.

This is a temporary solution and should be replaced by doing the DT parsing during

So, yes, let's see if we can use a card quirk instead. That's the first option.

Quoted 8 lines

Quoted 3 lines

A second option is simply to parse the DT subnode for a new DT property during mmc_sdio_init_card(). Along the lines of what we do for the broken-hpi DT binding for eMMC.

Let's try the first option. My understanding is that the problem affects only the specific model of the WiFi chip and it's not a board-specific problem. I'll add Broadcom driver people to CC for the next version of the patch, maybe they'll have something to say.

Okay, sounds reasonable. By looking at your latest attempt for a fix, I have two minor nitpicks, otherwise it looks good.

The nitpicks:
I suggest to rename MMC_QUIRK_HIGH_SPEED_CARD to MMC_QUIRK_HIGH_SPEED and mmc_card_need_high_speed_toggle() to mmc_card_quirk_hs().

11.12.2019 19:10, Ulf Hansson пишет:

Quoted 39 lines · Dmitry Osipenko

Quoted 37 lines

Hello Ulf,

11.12.2019 11:11, Ulf Hansson пишет:

Quoted 8 lines · Dmitry Osipenko

Quoted 5 lines

All Tegra20 boards that have embedded Broadcom WiFi SDIO chip are affected by a problem where WiFi chip reports CCCR v1.10, while it should v1.20. In a result high-speed mode isn't enabled for the WiFi card and this results in a malfunctioning SDIO communication.

Does that also mean SDIO_SPEED_SHS bit is set when reading SDIO_CCCR_SPEED?

Yes, the SDIO_SPEED_SHS bit is set.

Quoted 9 lines

Quoted 8 lines

brcmfmac: brcmf_sdio_readframes: read 304 bytes from channel 1 failed: -84
brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK

Downstream kernels are overriding card's CCCR info in SDHCI driver to fix the problem, let's do the same in upstream.

The change is inspired by omap_hsmmc_init_card() of OMAP's HSMMC driver, which overrides card's info for the TI wl1251 WiFi.

Quoted 8 lines

This is a temporary solution and should be replaced by doing the DT parsing during

So, yes, let's see if we can use a card quirk instead. That's the first option.

A second option is simply to parse the DT subnode for a new DT property during mmc_sdio_init_card(). Along the lines of what we do for the broken-hpi DT binding for eMMC.

Let's try the first option. My understanding is that the problem affects only the specific model of the WiFi chip and it's not a board-specific problem. I'll add Broadcom driver people to CC for the next version of the patch, maybe they'll have something to say.

Quoted 6 lines

Okay, sounds reasonable. By looking at your latest attempt for a fix, I have two minor nitpicks, otherwise it looks good.

The nitpicks:
I suggest to rename MMC_QUIRK_HIGH_SPEED_CARD to MMC_QUIRK_HIGH_SPEED and mmc_card_need_high_speed_toggle() to mmc_card_quirk_hs().

I'll take it into account, thanks.

11.12.2019 19:29, Dmitry Osipenko пишет:

Quoted 40 lines

11.12.2019 19:10, Ulf Hansson пишет:

Quoted 39 lines · Dmitry Osipenko

Quoted 37 lines

Hello Ulf,

11.12.2019 11:11, Ulf Hansson пишет:

Quoted 8 lines · Dmitry Osipenko

Quoted 5 lines

All Tegra20 boards that have embedded Broadcom WiFi SDIO chip are affected by a problem where WiFi chip reports CCCR v1.10, while it should v1.20. In a result high-speed mode isn't enabled for the WiFi card and this results in a malfunctioning SDIO communication.

Does that also mean SDIO_SPEED_SHS bit is set when reading SDIO_CCCR_SPEED?

Yes, the SDIO_SPEED_SHS bit is set.

Quoted 9 lines

Quoted 8 lines

brcmfmac: brcmf_sdio_readframes: read 304 bytes from channel 1 failed: -84
brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK

Downstream kernels are overriding card's CCCR info in SDHCI driver to fix the problem, let's do the same in upstream.

The change is inspired by omap_hsmmc_init_card() of OMAP's HSMMC driver, which overrides card's info for the TI wl1251 WiFi.

Quoted 8 lines

This is a temporary solution and should be replaced by doing the DT parsing during

So, yes, let's see if we can use a card quirk instead. That's the first option.

A second option is simply to parse the DT subnode for a new DT property during mmc_sdio_init_card(). Along the lines of what we do for the broken-hpi DT binding for eMMC.

Let's try the first option. My understanding is that the problem affects only the specific model of the WiFi chip and it's not a board-specific problem. I'll add Broadcom driver people to CC for the next version of the patch, maybe they'll have something to say.

Quoted 8 lines

Quoted 6 lines

Okay, sounds reasonable. By looking at your latest attempt for a fix, I have two minor nitpicks, otherwise it looks good.

The nitpicks:
I suggest to rename MMC_QUIRK_HIGH_SPEED_CARD to MMC_QUIRK_HIGH_SPEED and mmc_card_need_high_speed_toggle() to mmc_card_quirk_hs().

I'll take it into account, thanks.

Looks like I managed to figure out what's really going on:

1. The BCM4329 doc clearly states that High Speed is supported, see
page 49 (Section 11: WLAN Interfaces, SDIO v1.2)

https://www.cypress.com/file/298626/download

2. I googled for performance results of the BCM4329 SDIO WiFi and came
to a conclusion that ~40 Mbit/s is a realistic maximum of the WiFi-data throughput for NVIDIA Tegra20 boards due to antenna configuration limitations and whatever.

3. The Tegra's SDHCI clock is pre-configured to 48MHz at the time of
kernel's boot-up.

4. IIUC, the maximum clock rate for the legacy SD signaling mode is
~25MHz and that is more than enough for a 4-lane SDIO data-bus that allows up to 100 Mbit/s for the WiFi which is capped to 40 Mbit/s anyways.

5. Apparently MMC core doesn't limit the clock rate for the Normal
Speed cards.

So, I added "max-frequency = <25000000>;" to the SDHCI node of the board's device-tree and ta-da! WiFi works absolutely fine without the quirk! Thus the SDIO card quirk isn't really needed and I'm dropping it for now.

Ulf, do you know if it's a bug or a feature of the MMC core that it doesn't limit clock rate for the Normal Speed cards?

Quoted 56 lines

11.12.2019 19:29, Dmitry Osipenko пишет:

Quoted 40 lines

11.12.2019 19:10, Ulf Hansson пишет:

Quoted 39 lines · Dmitry Osipenko

Quoted 37 lines

Hello Ulf,

11.12.2019 11:11, Ulf Hansson пишет:

Quoted 8 lines · Dmitry Osipenko

Quoted 5 lines

All Tegra20 boards that have embedded Broadcom WiFi SDIO chip are affected by a problem where WiFi chip reports CCCR v1.10, while it should v1.20. In a result high-speed mode isn't enabled for the WiFi card and this results in a malfunctioning SDIO communication.

Does that also mean SDIO_SPEED_SHS bit is set when reading SDIO_CCCR_SPEED?

Yes, the SDIO_SPEED_SHS bit is set.

Quoted 9 lines

Quoted 8 lines

brcmfmac: brcmf_sdio_readframes: read 304 bytes from channel 1 failed: -84
brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK

Downstream kernels are overriding card's CCCR info in SDHCI driver to fix the problem, let's do the same in upstream.

The change is inspired by omap_hsmmc_init_card() of OMAP's HSMMC driver, which overrides card's info for the TI wl1251 WiFi.

Quoted 8 lines

This is a temporary solution and should be replaced by doing the DT parsing during

So, yes, let's see if we can use a card quirk instead. That's the first option.

A second option is simply to parse the DT subnode for a new DT property during mmc_sdio_init_card(). Along the lines of what we do for the broken-hpi DT binding for eMMC.

Let's try the first option. My understanding is that the problem affects only the specific model of the WiFi chip and it's not a board-specific problem. I'll add Broadcom driver people to CC for the next version of the patch, maybe they'll have something to say.

Quoted 8 lines

Quoted 6 lines

Okay, sounds reasonable. By looking at your latest attempt for a fix, I have two minor nitpicks, otherwise it looks good.

The nitpicks:
I suggest to rename MMC_QUIRK_HIGH_SPEED_CARD to MMC_QUIRK_HIGH_SPEED and mmc_card_need_high_speed_toggle() to mmc_card_quirk_hs().

I'll take it into account, thanks.

Looks like I managed to figure out what's really going on:

1. The BCM4329 doc clearly states that High Speed is supported, see
page 49 (Section 11: WLAN Interfaces, SDIO v1.2)

Quoted 6 lines

https://www.cypress.com/file/298626/download

2. I googled for performance results of the BCM4329 SDIO WiFi and came
to a conclusion that ~40 Mbit/s is a realistic maximum of the WiFi-data throughput for NVIDIA Tegra20 boards due to antenna configuration limitations and whatever.

Okay.

Quoted 7 lines

3. The Tegra's SDHCI clock is pre-configured to 48MHz at the time of
kernel's boot-up.

4. IIUC, the maximum clock rate for the legacy SD signaling mode is
~25MHz and that is more than enough for a 4-lane SDIO data-bus that allows up to 100 Mbit/s for the WiFi which is capped to 40 Mbit/s anyways.

Yes, I see.

Quoted 3 lines

5. Apparently MMC core doesn't limit the clock rate for the Normal
Speed cards.

It should, else it's a bug (I would be really surprised if that's the case, but who knows).

Quoted 9 lines

So, I added "max-frequency = <25000000>;" to the SDHCI node of the board's device-tree and ta-da! WiFi works absolutely fine without the quirk! Thus the SDIO card quirk isn't really needed and I'm dropping it for now.

Ulf, do you know if it's a bug or a feature of the MMC core that it doesn't limit clock rate for the Normal Speed cards?

It should limit the speed, else it's a bug. Can you perhaps check what the requested clock rate is via some debug prints in the host ops ->set_ios()? And also what the real rate becomes after dividers.

If it's not a bug in the core, I suspect that there may be generic problem dealing with initialization frequencies for sdhci-tegra.

For example, mmc_rescan_try_freq() tries to initialize the SDIO card at 400KHz, then 300, then 200 then 100 (in that order, and note *KHz*). When a frequency is successful, initialization continues and later on the clock rate should be increased to 25MHz, for legacy speed mode.