[PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Michael Garofalo]

This patch series adds a new bit to quirks2 for disabling the bounce
buffer.  On some hardware, this is required for proper operation.  An
example of such hardware is the SDHCI controller of the Nintendo Wii's
"Hollywood" chipset.  Without this patch, the onboard Broadcom 4318
Wi-Fi fails to connect to any networks.

Patch 1 introduces the new quirk bit.
Patch 2 applies it to sdhci-of-hlwd.

Michael Garofalo (2):
  mmc: sdhci: add quirk to disable the bounce buffer
  mmc: sdhci-of-hlwd: disable bounce buffer usage

 drivers/mmc/host/sdhci-of-hlwd.c | 1 +
 drivers/mmc/host/sdhci.c         | 8 +++++---
 drivers/mmc/host/sdhci.h         | 4 ++++
 3 files changed, 10 insertions(+), 3 deletions(-)

-- 
2.51.0

[PATCH 1/2] mmc: sdhci: add quirk to disable the bounce buffer

[Michael Garofalo]

On some controllers, using a bounce buffer can have negative effects.
For example, on the SDHCI controller in the Nintendo Wii's "Hollywood"
chipset, using bounce buffers causes the internal Broadcom 4318 Wi-Fi to
fail on most data transfers.  The SDHCI core already supports running
without bounce buffers, so this exposes a quirk to forcibly disable them
for a given controller.

Signed-off-by: Michael Garofalo <officialTechflashYT@gmail.com>
---
 drivers/mmc/host/sdhci.c | 8 +++++---
 drivers/mmc/host/sdhci.h | 4 ++++
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ac7e11f37af7..7bf531802057 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -4806,9 +4806,11 @@ int sdhci_setup_host(struct sdhci_host *host)
 	 */
 	mmc->max_blk_count = (host->quirks & SDHCI_QUIRK_NO_MULTIBLOCK) ? 1 : 65535;
 
-	if (mmc->max_segs == 1)
-		/* This may alter mmc->*_blk_* parameters */
-		sdhci_allocate_bounce_buffer(host);
+	if (!(host->quirks2 & SDHCI_QUIRK2_NO_BOUNCE_BUFFER)) {
+		if (mmc->max_segs == 1)
+			/* This may alter mmc->*_blk_* parameters */
+			sdhci_allocate_bounce_buffer(host);
+	}
 
 	return 0;
 
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 58fcbeaf281e..9a082add96db 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -536,6 +536,10 @@ struct sdhci_host {
 #define SDHCI_QUIRK2_USE_32BIT_BLK_CNT			(1<<18)
 /* Issue CMD and DATA reset together */
 #define SDHCI_QUIRK2_ISSUE_CMD_DAT_RESET_TOGETHER	(1<<19)
+/*
+ * Bounce buffers cannot work, don't use them.
+ */
+#define SDHCI_QUIRK2_NO_BOUNCE_BUFFER			(1<<20)
 
 	int irq;		/* Device IRQ */
 	void __iomem *ioaddr;	/* Mapped address */
-- 
2.51.0

[PATCH 2/2] mmc: sdhci-of-hlwd: disable bounce buffer usage

[Michael Garofalo]

On the SDHCI controller in the Nintendo Wii's "Hollywood" chipset, using
bounce buffers causes the internal Broadcom 4318 Wi-Fi to fail on most
data transfers.  Disabling bounce buffer usage allows reliable
transmission again.

Signed-off-by: Michael Garofalo <officialTechflashYT@gmail.com>
---
 drivers/mmc/host/sdhci-of-hlwd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/sdhci-of-hlwd.c b/drivers/mmc/host/sdhci-of-hlwd.c
index 5bb845d13599..59736ae85c14 100644
--- a/drivers/mmc/host/sdhci-of-hlwd.c
+++ b/drivers/mmc/host/sdhci-of-hlwd.c
@@ -63,6 +63,7 @@ static const struct sdhci_ops sdhci_hlwd_ops = {
 static const struct sdhci_pltfm_data sdhci_hlwd_pdata = {
 	.quirks = SDHCI_QUIRK_32BIT_DMA_ADDR |
 		  SDHCI_QUIRK_32BIT_DMA_SIZE,
+	.quirks2 = SDHCI_QUIRK2_NO_BOUNCE_BUFFER,
 	.ops = &sdhci_hlwd_ops,
 };
 
-- 
2.51.0

Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Adrian Hunter]

On 06/10/2025 04:36, Michael Garofalo wrote:
> This patch series adds a new bit to quirks2 for disabling the bounce
> buffer.  On some hardware, this is required for proper operation.  An
> example of such hardware is the SDHCI controller of the Nintendo Wii's
> "Hollywood" chipset.  Without this patch, the onboard Broadcom 4318
> Wi-Fi fails to connect to any networks.

The bounce buffer should not make any difference, so it is likely
a different problem that gets hidden when the bounce buffer is not
used.

Could you enable dynamic debug messages and show the messages
for the failing case?

Dynamic debug for mmc
---------------------

    Kernel must be configured:

        CONFIG_DYNAMIC_DEBUG=y

    To enable mmc debug via sysfs:

        echo 'file drivers/mmc/core/* +p' > /sys/kernel/debug/dynamic_debug/control
        echo 'file drivers/mmc/host/* +p' > /sys/kernel/debug/dynamic_debug/control

    To enable mmc debug via kernel command line:

        dyndbg="file drivers/mmc/core/* +p;file drivers/mmc/host/* +p"

    To disable mmc debug:

        echo 'file drivers/mmc/core/* -p' > /sys/kernel/debug/dynamic_debug/control
        echo 'file drivers/mmc/host/* -p' > /sys/kernel/debug/dynamic_debug/control

    More general information in kernel documentation in kernel tree:

        Documentation/admin-guide/dynamic-debug-howto.rst
	https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html


> 
> Patch 1 introduces the new quirk bit.
> Patch 2 applies it to sdhci-of-hlwd.
> 
> Michael Garofalo (2):
>   mmc: sdhci: add quirk to disable the bounce buffer
>   mmc: sdhci-of-hlwd: disable bounce buffer usage
> 
>  drivers/mmc/host/sdhci-of-hlwd.c | 1 +
>  drivers/mmc/host/sdhci.c         | 8 +++++---
>  drivers/mmc/host/sdhci.h         | 4 ++++
>  3 files changed, 10 insertions(+), 3 deletions(-)
> 

Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Adrian Hunter]

On 06/10/2025 10:35, Adrian Hunter wrote:
> On 06/10/2025 04:36, Michael Garofalo wrote:
>> This patch series adds a new bit to quirks2 for disabling the bounce
>> buffer.  On some hardware, this is required for proper operation.  An
>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>> "Hollywood" chipset.  Without this patch, the onboard Broadcom 4318
>> Wi-Fi fails to connect to any networks.
> 
> The bounce buffer should not make any difference, so it is likely
> a different problem that gets hidden when the bounce buffer is not
> used.
> 
> Could you enable dynamic debug messages and show the messages
> for the failing case?

Actually will also need to see the messages in the "fixed" case
to compare.

> 
> Dynamic debug for mmc
> ---------------------
> 
>     Kernel must be configured:
> 
>         CONFIG_DYNAMIC_DEBUG=y
> 
>     To enable mmc debug via sysfs:
> 
>         echo 'file drivers/mmc/core/* +p' > /sys/kernel/debug/dynamic_debug/control
>         echo 'file drivers/mmc/host/* +p' > /sys/kernel/debug/dynamic_debug/control
> 
>     To enable mmc debug via kernel command line:
> 
>         dyndbg="file drivers/mmc/core/* +p;file drivers/mmc/host/* +p"
> 
>     To disable mmc debug:
> 
>         echo 'file drivers/mmc/core/* -p' > /sys/kernel/debug/dynamic_debug/control
>         echo 'file drivers/mmc/host/* -p' > /sys/kernel/debug/dynamic_debug/control
> 
>     More general information in kernel documentation in kernel tree:
> 
>         Documentation/admin-guide/dynamic-debug-howto.rst
> 	https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html
> 
> 
>>
>> Patch 1 introduces the new quirk bit.
>> Patch 2 applies it to sdhci-of-hlwd.
>>
>> Michael Garofalo (2):
>>   mmc: sdhci: add quirk to disable the bounce buffer
>>   mmc: sdhci-of-hlwd: disable bounce buffer usage
>>
>>  drivers/mmc/host/sdhci-of-hlwd.c | 1 +
>>  drivers/mmc/host/sdhci.c         | 8 +++++---
>>  drivers/mmc/host/sdhci.h         | 4 ++++
>>  3 files changed, 10 insertions(+), 3 deletions(-)
>>
> 

Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Michael Garofalo]

Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Michael Garofalo]

> On 06/10/2025 10:35, Adrian Hunter wrote:
>> On 06/10/2025 04:36, Michael Garofalo wrote:
>>> This patch series adds a new bit to quirks2 for disabling the bounce
>>> buffer.  On some hardware, this is required for proper operation.  An
>>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>>> "Hollywood" chipset.  Without this patch, the onboard Broadcom 4318
>>> Wi-Fi fails to connect to any networks.
>> 
>> The bounce buffer should not make any difference, so it is likely
>> a different problem that gets hidden when the bounce buffer is not
>> used.
>> 
>>> Could you enable dynamic debug messages and show the messages
>>> for the failing case?
>>
>>Actually will also need to see the messages in the "fixed" case
>>to compare.
I'm afraid I won't be able to provide those easily, at least not with the
commands you've provided.  Since the rootfs is _also_ running from SD,
turning on full MMC logs like this produces an obscene amount of noise
from the storage, unrelated to the SDIO wireless.  It gets even worse with
my original intention, which was to save the logs to SD Card, (since my USB
Gecko serial console is rather flakey, and introduces corruption now and then),
since it's now logging the writes of it's own logs in a permanent loop.
If there's a way to narrow down the logs to specifically whatever portions
you're interested in, and filter out the noise, I would happily provide it.

(P.S. sorry about the blank message there, still working out how to deal with mailing lists)
>
>> 
>> Dynamic debug for mmc
>> ---------------------
>> 
>>     Kernel must be configured:
>> 
>>         CONFIG_DYNAMIC_DEBUG=y
>> 
>>     To enable mmc debug via sysfs:
>> 
>>         echo 'file drivers/mmc/core/* +p' > /sys/kernel/debug/dynamic_debug/control
>>         echo 'file drivers/mmc/host/* +p' > /sys/kernel/debug/dynamic_debug/control
>> 
>>     To enable mmc debug via kernel command line:
>> 
>>         dyndbg="file drivers/mmc/core/* +p;file drivers/mmc/host/* +p"
>> 
>>     To disable mmc debug:
>> 
>>         echo 'file drivers/mmc/core/* -p' > /sys/kernel/debug/dynamic_debug/control
>>         echo 'file drivers/mmc/host/* -p' > /sys/kernel/debug/dynamic_debug/control
>> 
>>     More general information in kernel documentation in kernel tree:
>> 
>>         Documentation/admin-guide/dynamic-debug-howto.rst
>> 	https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html
>> 
>> 
>>>
>>> Patch 1 introduces the new quirk bit.
>>> Patch 2 applies it to sdhci-of-hlwd.
>>>
>>> Michael Garofalo (2):
>>>   mmc: sdhci: add quirk to disable the bounce buffer
>>>   mmc: sdhci-of-hlwd: disable bounce buffer usage
>>>
>>>  drivers/mmc/host/sdhci-of-hlwd.c | 1 +
>>>  drivers/mmc/host/sdhci.c         | 8 +++++---
>>>  drivers/mmc/host/sdhci.h         | 4 ++++
>>>  3 files changed, 10 insertions(+), 3 deletions(-)
>>>
>> 

Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Adrian Hunter]

On 06/10/2025 12:28, Michael Garofalo wrote:
>> On 06/10/2025 10:35, Adrian Hunter wrote:
>>> On 06/10/2025 04:36, Michael Garofalo wrote:
>>>> This patch series adds a new bit to quirks2 for disabling the bounce
>>>> buffer.  On some hardware, this is required for proper operation.  An
>>>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>>>> "Hollywood" chipset.  Without this patch, the onboard Broadcom 4318
>>>> Wi-Fi fails to connect to any networks.
>>>
>>> The bounce buffer should not make any difference, so it is likely
>>> a different problem that gets hidden when the bounce buffer is not
>>> used.
>>>
>>>> Could you enable dynamic debug messages and show the messages
>>>> for the failing case?
>>>
>>> Actually will also need to see the messages in the "fixed" case
>>> to compare.
> I'm afraid I won't be able to provide those easily, at least not with the
> commands you've provided.  Since the rootfs is _also_ running from SD,
> turning on full MMC logs like this produces an obscene amount of noise
> from the storage, unrelated to the SDIO wireless.  It gets even worse with
> my original intention, which was to save the logs to SD Card, (since my USB
> Gecko serial console is rather flakey, and introduces corruption now and then),
> since it's now logging the writes of it's own logs in a permanent loop.
> If there's a way to narrow down the logs to specifically whatever portions
> you're interested in, and filter out the noise, I would happily provide it.

Are there any error messages?

Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Michael Garofalo]

> On 06/10/2025 12:28, Michael Garofalo wrote:
>>> On 06/10/2025 10:35, Adrian Hunter wrote:
>>>> On 06/10/2025 04:36, Michael Garofalo wrote:
>>>>> This patch series adds a new bit to quirks2 for disabling the bounce
>>>>> buffer.  On some hardware, this is required for proper operation.  An
>>>>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>>>>> "Hollywood" chipset.  Without this patch, the onboard Broadcom 4318
>>>>> Wi-Fi fails to connect to any networks.
>>>>
>>>> The bounce buffer should not make any difference, so it is likely
>>>> a different problem that gets hidden when the bounce buffer is not
>>>> used.
>>>>
>>>>> Could you enable dynamic debug messages and show the messages
>>>>> for the failing case?
>>>>
>>>> Actually will also need to see the messages in the "fixed" case
>>>> to compare.
>> I'm afraid I won't be able to provide those easily, at least not with the
>> commands you've provided.  Since the rootfs is _also_ running from SD,
>> turning on full MMC logs like this produces an obscene amount of noise
>> from the storage, unrelated to the SDIO wireless.  It gets even worse with
>> my original intention, which was to save the logs to SD Card, (since my USB
>> Gecko serial console is rather flakey, and introduces corruption now and then),
>> since it's now logging the writes of it's own logs in a permanent loop.
>> If there's a way to narrow down the logs to specifically whatever portions
>> you're interested in, and filter out the noise, I would happily provide it.
> 
> Are there any error messages?
If I drop the debug logs you mentioned so that I can actually see what's
going on (they produce hundreds of lines / sec), here's what the Wi-Fi card
actually reports with, vs without, MMC bounce buffers.  With bounce buffers on,
it takes several tries to load the firmware, and it can't authenticate to any
network.  I've tested and confirmed this effect on multiple consoles, across
multiple reboots, on multiple Wi-Fi networks.  Meanwhile with MMC bounce buffers
off, it's much more functional.

Logs with MMC bounce buffers *on* (without my patches):
[  168.492687] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
[  168.493516] ssb: Found chip with id 0x4710, rev 0x00 an package 0x00
[  168.508519] ssb: WARNING: Multiple ChipCommon found
[  168.510597] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
[  168.510886] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
[  168.530151] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
[  168.538447] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
[  168.719257] Broadcom 43xx driver loaded [ Features: S ]
[  168.722231] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
[  168.724613] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
[  168.740666] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
[  168.762630] ieee80211 phy0: Slected rate control algorithm 'minstrel_ht'
[  176.156693] b43-phy0: Loading OpenSource firmware version 410.31754
[  176.157159] b43-phy0: Hardware crypto acceleration not supported by firmware
[  179.993008] b43-phy0: Loading OpenSource firmware version 410.31754
[  179.994373] b43-phy0: Hardware crypto acceleration not supported by firmware
[  186.940346] b43-phy0: Loading OpenSource firmware version 410.31754
[  186.942559] b43-phy0: Hardware crypto acceleration not supported by firmware
[  216.368668] b43-phy0: Loading OpenSource firmware version 410.31754
[  216.369135] b43-phy0: Hardware crypto acceleration not supported by firmware
[  221.750016] b43-phy0: Loading OpenSource firmware version 410.31754
[  221.757700] b43-phy0: Hardware crypto acceleration not supported by firmware
[  223.437731] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
[  223.437764] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
[  223.648472] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
[  223.859770] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
[  224.064469] wlan0: authentication with da:b3:70:18:7c:14 timed out
[  226.045361] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
[  226.045393] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
[  226.248488] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
[  226.462378] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
[  226.664487] wlan0: authentication with da:b3:70:18:7c:14 timed out
[  250.424168] b43-phy0: Loading OpenSource firmware version 410.31754
[  250.425629] b43-phy0: Hardware crypto acceleration not supported by firmware
[  255.806790] b43-phy0: Loading OpenSource firmware version 410.31754
[  255.807256] b43-phy0: Hardware crypto acceleration not supported by firmware
[  257.467380] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
[  257.467414] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
[  257.672475] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
[  257.880474] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
[  258.093974] wlan0: authentication with da:b3:70:18:7c:14 timed out
[  284.326415] b43-phy0: Loading OpenSource firmware version 410.31754
[  284.326922] b43-phy0: Hardware crypto acceleration not supported by firmware
[  289.836233] b43-phy0: Loading OpenSource firmware version 410.31754
[  289.837612] b43-phy0: Hardware crypto acceleration not supported by firmware
[  291.528250] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
[  291.528283] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
[  291.736473] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
[  291.944482] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
[  292.152470] wlan0: authentication with da:b3:70:18:7c:14 timed out
<keeps trying and failing forever....>

Logs with MMC bounce buffers *off* (with my patches):
[  383.974268] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
[  383.975824] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
[  383.986645] ssb: WARNING: Multiple ChipCommon found
[  383.987414] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
[  383.987744] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
[  383.995898] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
[  383.996249] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
[  384.077562] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
[  384.077687] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
[  384.086571] Broadcom 43xx driver loaded [ Features: S ]
[  384.144620] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
[  384.190831] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[  395.097838] b43-phy0: Loading OpenSource firmware version 410.31754
[  395.098158] b43-phy0: Hardware crypto acceleration not supported by firmware
[  397.667851] b43-phy0: Loading OpenSource firmware version 410.31754
[  397.668171] b43-phy0: Hardware crypto acceleration not supported by firmware
[  403.940787] b43-phy0: Loading OpenSource firmware version 410.31754
[  403.941110] b43-phy0: Hardware crypto acceleration not supported by firmware
[  405.366065] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
[  405.366095] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
[  405.389013] wlan0: authenticated
[  405.392814] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
[  405.600498] wlan0: associate with da:b3:70:18:7c:14 (try 2/3)
[  405.808479] wlan0: associate with da:b3:70:18:7c:14 (try 3/3)
[  406.016481] wlan0: association with da:b3:70:18:7c:14 timed out
[  414.301216] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
[  414.301245] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
[  414.351544] wlan0: authenticated
[  414.403769] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
[  414.422775] wlan0: RX AssocResp from da:b3:70:18:7c:14 (capab=0x1411 status=0 aid=25)
[  414.431879] wlan0: associated
[  415.272393] wlan0: Limiting TX power to 36 (36 - 0) dBm as advertised by da:b3:70:18:7c:14

If there's anything further that would be useful here, let me know and I'd be happy to provide them.

Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Adrian Hunter]

On 08/10/2025 04:10, Michael Garofalo wrote:
>> On 06/10/2025 12:28, Michael Garofalo wrote:
>>>> On 06/10/2025 10:35, Adrian Hunter wrote:
>>>>> On 06/10/2025 04:36, Michael Garofalo wrote:
>>>>>> This patch series adds a new bit to quirks2 for disabling the bounce
>>>>>> buffer.  On some hardware, this is required for proper operation.  An
>>>>>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>>>>>> "Hollywood" chipset.  Without this patch, the onboard Broadcom 4318
>>>>>> Wi-Fi fails to connect to any networks.
>>>>>
>>>>> The bounce buffer should not make any difference, so it is likely
>>>>> a different problem that gets hidden when the bounce buffer is not
>>>>> used.
>>>>>
>>>>>> Could you enable dynamic debug messages and show the messages
>>>>>> for the failing case?
>>>>>
>>>>> Actually will also need to see the messages in the "fixed" case
>>>>> to compare.
>>> I'm afraid I won't be able to provide those easily, at least not with the
>>> commands you've provided.  Since the rootfs is _also_ running from SD,
>>> turning on full MMC logs like this produces an obscene amount of noise
>>> from the storage, unrelated to the SDIO wireless.  It gets even worse with
>>> my original intention, which was to save the logs to SD Card, (since my USB
>>> Gecko serial console is rather flakey, and introduces corruption now and then),
>>> since it's now logging the writes of it's own logs in a permanent loop.
>>> If there's a way to narrow down the logs to specifically whatever portions
>>> you're interested in, and filter out the noise, I would happily provide it.
>>
>> Are there any error messages?
> If I drop the debug logs you mentioned so that I can actually see what's
> going on (they produce hundreds of lines / sec), here's what the Wi-Fi card
> actually reports with, vs without, MMC bounce buffers.  With bounce buffers on,
> it takes several tries to load the firmware, and it can't authenticate to any
> network.  I've tested and confirmed this effect on multiple consoles, across
> multiple reboots, on multiple Wi-Fi networks.  Meanwhile with MMC bounce buffers
> off, it's much more functional.
> 
> Logs with MMC bounce buffers *on* (without my patches):
> [  168.492687] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> [  168.493516] ssb: Found chip with id 0x4710, rev 0x00 an package 0x00
> [  168.508519] ssb: WARNING: Multiple ChipCommon found
> [  168.510597] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
> [  168.510886] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
> [  168.530151] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
> [  168.538447] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
> [  168.719257] Broadcom 43xx driver loaded [ Features: S ]
> [  168.722231] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
> [  168.724613] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
> [  168.740666] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
> [  168.762630] ieee80211 phy0: Slected rate control algorithm 'minstrel_ht'
> [  176.156693] b43-phy0: Loading OpenSource firmware version 410.31754
> [  176.157159] b43-phy0: Hardware crypto acceleration not supported by firmware
> [  179.993008] b43-phy0: Loading OpenSource firmware version 410.31754
> [  179.994373] b43-phy0: Hardware crypto acceleration not supported by firmware
> [  186.940346] b43-phy0: Loading OpenSource firmware version 410.31754
> [  186.942559] b43-phy0: Hardware crypto acceleration not supported by firmware
> [  216.368668] b43-phy0: Loading OpenSource firmware version 410.31754
> [  216.369135] b43-phy0: Hardware crypto acceleration not supported by firmware
> [  221.750016] b43-phy0: Loading OpenSource firmware version 410.31754
> [  221.757700] b43-phy0: Hardware crypto acceleration not supported by firmware
> [  223.437731] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
> [  223.437764] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
> [  223.648472] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
> [  223.859770] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
> [  224.064469] wlan0: authentication with da:b3:70:18:7c:14 timed out
> [  226.045361] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
> [  226.045393] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
> [  226.248488] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
> [  226.462378] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
> [  226.664487] wlan0: authentication with da:b3:70:18:7c:14 timed out
> [  250.424168] b43-phy0: Loading OpenSource firmware version 410.31754
> [  250.425629] b43-phy0: Hardware crypto acceleration not supported by firmware
> [  255.806790] b43-phy0: Loading OpenSource firmware version 410.31754
> [  255.807256] b43-phy0: Hardware crypto acceleration not supported by firmware
> [  257.467380] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
> [  257.467414] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
> [  257.672475] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
> [  257.880474] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
> [  258.093974] wlan0: authentication with da:b3:70:18:7c:14 timed out
> [  284.326415] b43-phy0: Loading OpenSource firmware version 410.31754
> [  284.326922] b43-phy0: Hardware crypto acceleration not supported by firmware
> [  289.836233] b43-phy0: Loading OpenSource firmware version 410.31754
> [  289.837612] b43-phy0: Hardware crypto acceleration not supported by firmware
> [  291.528250] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
> [  291.528283] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
> [  291.736473] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
> [  291.944482] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
> [  292.152470] wlan0: authentication with da:b3:70:18:7c:14 timed out
> <keeps trying and failing forever....>
> 
> Logs with MMC bounce buffers *off* (with my patches):
> [  383.974268] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> [  383.975824] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
> [  383.986645] ssb: WARNING: Multiple ChipCommon found
> [  383.987414] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
> [  383.987744] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
> [  383.995898] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
> [  383.996249] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
> [  384.077562] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
> [  384.077687] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
> [  384.086571] Broadcom 43xx driver loaded [ Features: S ]
> [  384.144620] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
> [  384.190831] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> [  395.097838] b43-phy0: Loading OpenSource firmware version 410.31754
> [  395.098158] b43-phy0: Hardware crypto acceleration not supported by firmware
> [  397.667851] b43-phy0: Loading OpenSource firmware version 410.31754
> [  397.668171] b43-phy0: Hardware crypto acceleration not supported by firmware
> [  403.940787] b43-phy0: Loading OpenSource firmware version 410.31754
> [  403.941110] b43-phy0: Hardware crypto acceleration not supported by firmware
> [  405.366065] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
> [  405.366095] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
> [  405.389013] wlan0: authenticated
> [  405.392814] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
> [  405.600498] wlan0: associate with da:b3:70:18:7c:14 (try 2/3)
> [  405.808479] wlan0: associate with da:b3:70:18:7c:14 (try 3/3)
> [  406.016481] wlan0: association with da:b3:70:18:7c:14 timed out
> [  414.301216] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
> [  414.301245] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
> [  414.351544] wlan0: authenticated
> [  414.403769] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
> [  414.422775] wlan0: RX AssocResp from da:b3:70:18:7c:14 (capab=0x1411 status=0 aid=25)
> [  414.431879] wlan0: associated
> [  415.272393] wlan0: Limiting TX power to 36 (36 - 0) dBm as advertised by da:b3:70:18:7c:14
> 
> If there's anything further that would be useful here, let me know and I'd be happy to provide them.

Seems the SDIO function driver b43-sdio does not print any error
messages.  All the error paths in drivers/ssb/sdio.c print debug
messages instead.

I would suggest the following, which would limit messages to
host mmc1 which is what is shown in message "b43-sdio mmc1:0001:1:
Chip ID 14e4:4318"

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 860378bea557..2719b21783ad 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -169,33 +169,33 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
 	 * - The card was removed (...so just complete everything no matter
 	 *   if there are errors or retries)
 	 */
-	if (!err || !cmd->retries || mmc_card_removed(host->card)) {
+	if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
 		mmc_should_fail_request(host, mrq);
 
 		if (!host->ongoing_mrq)
 			led_trigger_event(host->led, LED_OFF);
 
 		if (mrq->sbc) {
-			pr_debug("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
+			pr_info("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
 				mmc_hostname(host), mrq->sbc->opcode,
 				mrq->sbc->error,
 				mrq->sbc->resp[0], mrq->sbc->resp[1],
 				mrq->sbc->resp[2], mrq->sbc->resp[3]);
 		}
 
-		pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
+		pr_info("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
 			mmc_hostname(host), cmd->opcode, err,
 			cmd->resp[0], cmd->resp[1],
 			cmd->resp[2], cmd->resp[3]);
 
 		if (mrq->data) {
-			pr_debug("%s:     %d bytes transferred: %d\n",
+			pr_info("%s:     %d bytes transferred: %d\n",
 				mmc_hostname(host),
 				mrq->data->bytes_xfered, mrq->data->error);
 		}
 
 		if (mrq->stop) {
-			pr_debug("%s:     (CMD%u): %d: %08x %08x %08x %08x\n",
+			pr_info("%s:     (CMD%u): %d: %08x %08x %08x %08x\n",
 				mmc_hostname(host), mrq->stop->opcode,
 				mrq->stop->error,
 				mrq->stop->resp[0], mrq->stop->resp[1],

Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Michael Garofalo]

> On 08/10/2025 04:10, Michael Garofalo wrote:
>>> On 06/10/2025 12:28, Michael Garofalo wrote:
>>>>> On 06/10/2025 10:35, Adrian Hunter wrote:
>>>>>> On 06/10/2025 04:36, Michael Garofalo wrote:
>>>>>>> This patch series adds a new bit to quirks2 for disabling the bounce
>>>>>>> buffer.  On some hardware, this is required for proper operation.  An
>>>>>>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>>>>>>> "Hollywood" chipset.  Without this patch, the onboard Broadcom 4318
>>>>>>> Wi-Fi fails to connect to any networks.
>>>>>>
>>>>>> The bounce buffer should not make any difference, so it is likely
>>>>>> a different problem that gets hidden when the bounce buffer is not
>>>>>> used.
>>>>>>
>>>>>>> Could you enable dynamic debug messages and show the messages
>>>>>>> for the failing case?
>>>>>>
>>>>>> Actually will also need to see the messages in the "fixed" case
>>>>>> to compare.
>>>> I'm afraid I won't be able to provide those easily, at least not with the
>>>> commands you've provided.  Since the rootfs is _also_ running from SD,
>>>> turning on full MMC logs like this produces an obscene amount of noise
>>>> from the storage, unrelated to the SDIO wireless.  It gets even worse with
>>>> my original intention, which was to save the logs to SD Card, (since my USB
>>>> Gecko serial console is rather flakey, and introduces corruption now and then),
>>>> since it's now logging the writes of it's own logs in a permanent loop.
>>>> If there's a way to narrow down the logs to specifically whatever portions
>>>> you're interested in, and filter out the noise, I would happily provide it.
>>>
>>> Are there any error messages?
>> If I drop the debug logs you mentioned so that I can actually see what's
>> going on (they produce hundreds of lines / sec), here's what the Wi-Fi card
>> actually reports with, vs without, MMC bounce buffers.  With bounce buffers on,
>> it takes several tries to load the firmware, and it can't authenticate to any
>> network.  I've tested and confirmed this effect on multiple consoles, across
>> multiple reboots, on multiple Wi-Fi networks.  Meanwhile with MMC bounce buffers
>> off, it's much more functional.
>> 
>> Logs with MMC bounce buffers *on* (without my patches):
>> [  168.492687] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>> [  168.493516] ssb: Found chip with id 0x4710, rev 0x00 an package 0x00
>> [  168.508519] ssb: WARNING: Multiple ChipCommon found
>> [  168.510597] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>> [  168.510886] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>> [  168.530151] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>> [  168.538447] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>> [  168.719257] Broadcom 43xx driver loaded [ Features: S ]
>> [  168.722231] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>> [  168.724613] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>> [  168.740666] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>> [  168.762630] ieee80211 phy0: Slected rate control algorithm 'minstrel_ht'
>> [  176.156693] b43-phy0: Loading OpenSource firmware version 410.31754
>> [  176.157159] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [  179.993008] b43-phy0: Loading OpenSource firmware version 410.31754
>> [  179.994373] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [  186.940346] b43-phy0: Loading OpenSource firmware version 410.31754
>> [  186.942559] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [  216.368668] b43-phy0: Loading OpenSource firmware version 410.31754
>> [  216.369135] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [  221.750016] b43-phy0: Loading OpenSource firmware version 410.31754
>> [  221.757700] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [  223.437731] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>> [  223.437764] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>> [  223.648472] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>> [  223.859770] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>> [  224.064469] wlan0: authentication with da:b3:70:18:7c:14 timed out
>> [  226.045361] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>> [  226.045393] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>> [  226.248488] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>> [  226.462378] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>> [  226.664487] wlan0: authentication with da:b3:70:18:7c:14 timed out
>> [  250.424168] b43-phy0: Loading OpenSource firmware version 410.31754
>> [  250.425629] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [  255.806790] b43-phy0: Loading OpenSource firmware version 410.31754
>> [  255.807256] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [  257.467380] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>> [  257.467414] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>> [  257.672475] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>> [  257.880474] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>> [  258.093974] wlan0: authentication with da:b3:70:18:7c:14 timed out
>> [  284.326415] b43-phy0: Loading OpenSource firmware version 410.31754
>> [  284.326922] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [  289.836233] b43-phy0: Loading OpenSource firmware version 410.31754
>> [  289.837612] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [  291.528250] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>> [  291.528283] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>> [  291.736473] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>> [  291.944482] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>> [  292.152470] wlan0: authentication with da:b3:70:18:7c:14 timed out
>> <keeps trying and failing forever....>
>> 
>> Logs with MMC bounce buffers *off* (with my patches):
>> [  383.974268] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>> [  383.975824] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
>> [  383.986645] ssb: WARNING: Multiple ChipCommon found
>> [  383.987414] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>> [  383.987744] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>> [  383.995898] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>> [  383.996249] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>> [  384.077562] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>> [  384.077687] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>> [  384.086571] Broadcom 43xx driver loaded [ Features: S ]
>> [  384.144620] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>> [  384.190831] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
>> [  395.097838] b43-phy0: Loading OpenSource firmware version 410.31754
>> [  395.098158] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [  397.667851] b43-phy0: Loading OpenSource firmware version 410.31754
>> [  397.668171] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [  403.940787] b43-phy0: Loading OpenSource firmware version 410.31754
>> [  403.941110] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [  405.366065] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>> [  405.366095] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>> [  405.389013] wlan0: authenticated
>> [  405.392814] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>> [  405.600498] wlan0: associate with da:b3:70:18:7c:14 (try 2/3)
>> [  405.808479] wlan0: associate with da:b3:70:18:7c:14 (try 3/3)
>> [  406.016481] wlan0: association with da:b3:70:18:7c:14 timed out
>> [  414.301216] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>> [  414.301245] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>> [  414.351544] wlan0: authenticated
>> [  414.403769] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>> [  414.422775] wlan0: RX AssocResp from da:b3:70:18:7c:14 (capab=0x1411 status=0 aid=25)
>> [  414.431879] wlan0: associated
>> [  415.272393] wlan0: Limiting TX power to 36 (36 - 0) dBm as advertised by da:b3:70:18:7c:14
>> 
>> If there's anything further that would be useful here, let me know and I'd be happy to provide them.
> 
> Seems the SDIO function driver b43-sdio does not print any error
> messages.  All the error paths in drivers/ssb/sdio.c print debug
> messages instead.
> 
> I would suggest the following, which would limit messages to
> host mmc1 which is what is shown in message "b43-sdio mmc1:0001:1:
> Chip ID 14e4:4318"
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 860378bea557..2719b21783ad 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -169,33 +169,33 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
>  	 * - The card was removed (...so just complete everything no matter
>  	 *   if there are errors or retries)
>  	 */
> -	if (!err || !cmd->retries || mmc_card_removed(host->card)) {
> +	if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
>  		mmc_should_fail_request(host, mrq);
>  
>  		if (!host->ongoing_mrq)
>  			led_trigger_event(host->led, LED_OFF);
>  
>  		if (mrq->sbc) {
> -			pr_debug("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
> +			pr_info("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
>  				mmc_hostname(host), mrq->sbc->opcode,
>  				mrq->sbc->error,
>  				mrq->sbc->resp[0], mrq->sbc->resp[1],
>  				mrq->sbc->resp[2], mrq->sbc->resp[3]);
>  		}
>  
> -		pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
> +		pr_info("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
>  			mmc_hostname(host), cmd->opcode, err,
>  			cmd->resp[0], cmd->resp[1],
>  			cmd->resp[2], cmd->resp[3]);
>  
>  		if (mrq->data) {
> -			pr_debug("%s:     %d bytes transferred: %d\n",
> +			pr_info("%s:     %d bytes transferred: %d\n",
>  				mmc_hostname(host),
>  				mrq->data->bytes_xfered, mrq->data->error);
>  		}
>  
>  		if (mrq->stop) {
> -			pr_debug("%s:     (CMD%u): %d: %08x %08x %08x %08x\n",
> +			pr_info("%s:     (CMD%u): %d: %08x %08x %08x %08x\n",
>  				mmc_hostname(host), mrq->stop->opcode,
>  				mrq->stop->error,
>  				mrq->stop->resp[0], mrq->stop->resp[1],

With these patches, I still get copious amounts of spam, but at least relevant
to the wifi card now.
Here's a hopefully useful snippet (it's just a lot of these, from what I could see),
from with my patches:

[  154.177276] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[  154.177297] mmc1:     4 bytes transferred: 0
<...>
[  186.707195] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[  186.707217] mmc1:     20 bytes transferred: 0
[  186.707358] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[  186.707382] mmc1:     384 bytes transferred: 0
[  186.707477] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[  186.707498] mmc1:     24 bytes transferred: 0

And the one from without is very similar, except I noticed this pattern:
[   85.942269] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[   85.942299] mmc1:     4 bytes transferred: 0
[   85.942523] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[   85.942555] mmc1:     4 bytes transferred: 0
[   85.944548] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[   85.944581] mmc1:     2 bytes transferred: 0
[   85.944777] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[   85.945160] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[   85.945187] mmc1:     2 bytes transferred: 0
... occasionally, some of the requests don't have an "[x] bytes transferred: 0".

Hopefully these help.  I can get a capture of the entire log spam and
put it on on pastebin or something, if that would be more useful.

Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Adrian Hunter]

On 11/10/2025 00:16, Michael Garofalo wrote:
>> On 08/10/2025 04:10, Michael Garofalo wrote:
>>>> On 06/10/2025 12:28, Michael Garofalo wrote:
>>>>>> On 06/10/2025 10:35, Adrian Hunter wrote:
>>>>>>> On 06/10/2025 04:36, Michael Garofalo wrote:
>>>>>>>> This patch series adds a new bit to quirks2 for disabling the bounce
>>>>>>>> buffer.  On some hardware, this is required for proper operation.  An
>>>>>>>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>>>>>>>> "Hollywood" chipset.  Without this patch, the onboard Broadcom 4318
>>>>>>>> Wi-Fi fails to connect to any networks.
>>>>>>>
>>>>>>> The bounce buffer should not make any difference, so it is likely
>>>>>>> a different problem that gets hidden when the bounce buffer is not
>>>>>>> used.
>>>>>>>
>>>>>>>> Could you enable dynamic debug messages and show the messages
>>>>>>>> for the failing case?
>>>>>>>
>>>>>>> Actually will also need to see the messages in the "fixed" case
>>>>>>> to compare.
>>>>> I'm afraid I won't be able to provide those easily, at least not with the
>>>>> commands you've provided.  Since the rootfs is _also_ running from SD,
>>>>> turning on full MMC logs like this produces an obscene amount of noise
>>>>> from the storage, unrelated to the SDIO wireless.  It gets even worse with
>>>>> my original intention, which was to save the logs to SD Card, (since my USB
>>>>> Gecko serial console is rather flakey, and introduces corruption now and then),
>>>>> since it's now logging the writes of it's own logs in a permanent loop.
>>>>> If there's a way to narrow down the logs to specifically whatever portions
>>>>> you're interested in, and filter out the noise, I would happily provide it.
>>>>
>>>> Are there any error messages?
>>> If I drop the debug logs you mentioned so that I can actually see what's
>>> going on (they produce hundreds of lines / sec), here's what the Wi-Fi card
>>> actually reports with, vs without, MMC bounce buffers.  With bounce buffers on,
>>> it takes several tries to load the firmware, and it can't authenticate to any
>>> network.  I've tested and confirmed this effect on multiple consoles, across
>>> multiple reboots, on multiple Wi-Fi networks.  Meanwhile with MMC bounce buffers
>>> off, it's much more functional.
>>>
>>> Logs with MMC bounce buffers *on* (without my patches):
>>> [  168.492687] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>>> [  168.493516] ssb: Found chip with id 0x4710, rev 0x00 an package 0x00
>>> [  168.508519] ssb: WARNING: Multiple ChipCommon found
>>> [  168.510597] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>>> [  168.510886] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>>> [  168.530151] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>>> [  168.538447] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>>> [  168.719257] Broadcom 43xx driver loaded [ Features: S ]
>>> [  168.722231] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>> [  168.724613] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>> [  168.740666] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>>> [  168.762630] ieee80211 phy0: Slected rate control algorithm 'minstrel_ht'
>>> [  176.156693] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [  176.157159] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [  179.993008] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [  179.994373] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [  186.940346] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [  186.942559] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [  216.368668] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [  216.369135] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [  221.750016] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [  221.757700] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [  223.437731] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>> [  223.437764] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>> [  223.648472] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>> [  223.859770] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>> [  224.064469] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>> [  226.045361] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>> [  226.045393] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>> [  226.248488] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>> [  226.462378] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>> [  226.664487] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>> [  250.424168] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [  250.425629] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [  255.806790] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [  255.807256] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [  257.467380] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>> [  257.467414] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>> [  257.672475] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>> [  257.880474] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>> [  258.093974] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>> [  284.326415] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [  284.326922] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [  289.836233] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [  289.837612] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [  291.528250] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>> [  291.528283] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>> [  291.736473] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>> [  291.944482] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>> [  292.152470] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>> <keeps trying and failing forever....>
>>>
>>> Logs with MMC bounce buffers *off* (with my patches):
>>> [  383.974268] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>>> [  383.975824] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
>>> [  383.986645] ssb: WARNING: Multiple ChipCommon found
>>> [  383.987414] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>>> [  383.987744] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>>> [  383.995898] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>>> [  383.996249] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>>> [  384.077562] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>> [  384.077687] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>> [  384.086571] Broadcom 43xx driver loaded [ Features: S ]
>>> [  384.144620] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>>> [  384.190831] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
>>> [  395.097838] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [  395.098158] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [  397.667851] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [  397.668171] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [  403.940787] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [  403.941110] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [  405.366065] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>> [  405.366095] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>> [  405.389013] wlan0: authenticated
>>> [  405.392814] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>>> [  405.600498] wlan0: associate with da:b3:70:18:7c:14 (try 2/3)
>>> [  405.808479] wlan0: associate with da:b3:70:18:7c:14 (try 3/3)
>>> [  406.016481] wlan0: association with da:b3:70:18:7c:14 timed out
>>> [  414.301216] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>> [  414.301245] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>> [  414.351544] wlan0: authenticated
>>> [  414.403769] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>>> [  414.422775] wlan0: RX AssocResp from da:b3:70:18:7c:14 (capab=0x1411 status=0 aid=25)
>>> [  414.431879] wlan0: associated
>>> [  415.272393] wlan0: Limiting TX power to 36 (36 - 0) dBm as advertised by da:b3:70:18:7c:14
>>>
>>> If there's anything further that would be useful here, let me know and I'd be happy to provide them.
>>
>> Seems the SDIO function driver b43-sdio does not print any error
>> messages.  All the error paths in drivers/ssb/sdio.c print debug
>> messages instead.
>>
>> I would suggest the following, which would limit messages to
>> host mmc1 which is what is shown in message "b43-sdio mmc1:0001:1:
>> Chip ID 14e4:4318"
>>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index 860378bea557..2719b21783ad 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -169,33 +169,33 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
>>  	 * - The card was removed (...so just complete everything no matter
>>  	 *   if there are errors or retries)
>>  	 */
>> -	if (!err || !cmd->retries || mmc_card_removed(host->card)) {
>> +	if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
>>  		mmc_should_fail_request(host, mrq);
>>  
>>  		if (!host->ongoing_mrq)
>>  			led_trigger_event(host->led, LED_OFF);
>>  
>>  		if (mrq->sbc) {
>> -			pr_debug("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
>> +			pr_info("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
>>  				mmc_hostname(host), mrq->sbc->opcode,
>>  				mrq->sbc->error,
>>  				mrq->sbc->resp[0], mrq->sbc->resp[1],
>>  				mrq->sbc->resp[2], mrq->sbc->resp[3]);
>>  		}
>>  
>> -		pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
>> +		pr_info("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
>>  			mmc_hostname(host), cmd->opcode, err,
>>  			cmd->resp[0], cmd->resp[1],
>>  			cmd->resp[2], cmd->resp[3]);
>>  
>>  		if (mrq->data) {
>> -			pr_debug("%s:     %d bytes transferred: %d\n",
>> +			pr_info("%s:     %d bytes transferred: %d\n",
>>  				mmc_hostname(host),
>>  				mrq->data->bytes_xfered, mrq->data->error);
>>  		}
>>  
>>  		if (mrq->stop) {
>> -			pr_debug("%s:     (CMD%u): %d: %08x %08x %08x %08x\n",
>> +			pr_info("%s:     (CMD%u): %d: %08x %08x %08x %08x\n",
>>  				mmc_hostname(host), mrq->stop->opcode,
>>  				mrq->stop->error,
>>  				mrq->stop->resp[0], mrq->stop->resp[1],
> 
> With these patches, I still get copious amounts of spam, but at least relevant
> to the wifi card now.
> Here's a hopefully useful snippet (it's just a lot of these, from what I could see),
> from with my patches:
> 
> [  154.177276] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [  154.177297] mmc1:     4 bytes transferred: 0
> <...>
> [  186.707195] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [  186.707217] mmc1:     20 bytes transferred: 0
> [  186.707358] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [  186.707382] mmc1:     384 bytes transferred: 0
> [  186.707477] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [  186.707498] mmc1:     24 bytes transferred: 0
> 
> And the one from without is very similar, except I noticed this pattern:
> [   85.942269] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [   85.942299] mmc1:     4 bytes transferred: 0
> [   85.942523] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [   85.942555] mmc1:     4 bytes transferred: 0
> [   85.944548] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [   85.944581] mmc1:     2 bytes transferred: 0
> [   85.944777] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [   85.945160] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [   85.945187] mmc1:     2 bytes transferred: 0
> ... occasionally, some of the requests don't have an "[x] bytes transferred: 0".
> 
> Hopefully these help.  I can get a capture of the entire log spam and
> put it on on pastebin or something, if that would be more useful.

Need to know if there are any errors.  In "[x] bytes transferred: 0"
messages, the "0" is the error code i.e. no error.  So you might be able
to find errors like:

	dmesg | grep 'bytes transferred' | grep -v 'bytes transferred: 0'

Also the debug patch could be tweaked to show errors only:

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 2719b21783ad..7b18fe6d5738 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -169,7 +169,7 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
 	 * - The card was removed (...so just complete everything no matter
 	 *   if there are errors or retries)
 	 */
-	if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
+	if (host->index == 1 && (err || (mrq->data && mrq->data->error))) {
 		mmc_should_fail_request(host, mrq);
 
 		if (!host->ongoing_mrq)

Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Michael Garofalo]

> On 11/10/2025 00:16, Michael Garofalo wrote:
>>> On 08/10/2025 04:10, Michael Garofalo wrote:
>>>>> On 06/10/2025 12:28, Michael Garofalo wrote:
>>>>>>> On 06/10/2025 10:35, Adrian Hunter wrote:
>>>>>>>> On 06/10/2025 04:36, Michael Garofalo wrote:
>>>>>>>>> This patch series adds a new bit to quirks2 for disabling the bounce
>>>>>>>>> buffer.  On some hardware, this is required for proper operation.  An
>>>>>>>>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>>>>>>>>> "Hollywood" chipset.  Without this patch, the onboard Broadcom 4318
>>>>>>>>> Wi-Fi fails to connect to any networks.
>>>>>>>>
>>>>>>>> The bounce buffer should not make any difference, so it is likely
>>>>>>>> a different problem that gets hidden when the bounce buffer is not
>>>>>>>> used.
>>>>>>>>
>>>>>>>>> Could you enable dynamic debug messages and show the messages
>>>>>>>>> for the failing case?
>>>>>>>>
>>>>>>>> Actually will also need to see the messages in the "fixed" case
>>>>>>>> to compare.
>>>>>> I'm afraid I won't be able to provide those easily, at least not with the
>>>>>> commands you've provided.  Since the rootfs is _also_ running from SD,
>>>>>> turning on full MMC logs like this produces an obscene amount of noise
>>>>>> from the storage, unrelated to the SDIO wireless.  It gets even worse with
>>>>>> my original intention, which was to save the logs to SD Card, (since my USB
>>>>>> Gecko serial console is rather flakey, and introduces corruption now and then),
>>>>>> since it's now logging the writes of it's own logs in a permanent loop.
>>>>>> If there's a way to narrow down the logs to specifically whatever portions
>>>>>> you're interested in, and filter out the noise, I would happily provide it.
>>>>>
>>>>> Are there any error messages?
>>>> If I drop the debug logs you mentioned so that I can actually see what's
>>>> going on (they produce hundreds of lines / sec), here's what the Wi-Fi card
>>>> actually reports with, vs without, MMC bounce buffers.  With bounce buffers on,
>>>> it takes several tries to load the firmware, and it can't authenticate to any
>>>> network.  I've tested and confirmed this effect on multiple consoles, across
>>>> multiple reboots, on multiple Wi-Fi networks.  Meanwhile with MMC bounce buffers
>>>> off, it's much more functional.
>>>>
>>>> Logs with MMC bounce buffers *on* (without my patches):
>>>> [  168.492687] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>>>> [  168.493516] ssb: Found chip with id 0x4710, rev 0x00 an package 0x00
>>>> [  168.508519] ssb: WARNING: Multiple ChipCommon found
>>>> [  168.510597] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>>>> [  168.510886] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>>>> [  168.530151] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>>>> [  168.538447] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>>>> [  168.719257] Broadcom 43xx driver loaded [ Features: S ]
>>>> [  168.722231] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>>> [  168.724613] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>>> [  168.740666] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>>>> [  168.762630] ieee80211 phy0: Slected rate control algorithm 'minstrel_ht'
>>>> [  176.156693] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [  176.157159] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [  179.993008] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [  179.994373] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [  186.940346] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [  186.942559] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [  216.368668] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [  216.369135] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [  221.750016] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [  221.757700] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [  223.437731] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>> [  223.437764] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>> [  223.648472] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>>> [  223.859770] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>>> [  224.064469] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>>> [  226.045361] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>> [  226.045393] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>> [  226.248488] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>>> [  226.462378] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>>> [  226.664487] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>>> [  250.424168] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [  250.425629] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [  255.806790] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [  255.807256] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [  257.467380] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>> [  257.467414] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>> [  257.672475] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>>> [  257.880474] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>>> [  258.093974] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>>> [  284.326415] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [  284.326922] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [  289.836233] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [  289.837612] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [  291.528250] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>> [  291.528283] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>> [  291.736473] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>>> [  291.944482] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>>> [  292.152470] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>>> <keeps trying and failing forever....>
>>>>
>>>> Logs with MMC bounce buffers *off* (with my patches):
>>>> [  383.974268] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>>>> [  383.975824] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
>>>> [  383.986645] ssb: WARNING: Multiple ChipCommon found
>>>> [  383.987414] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>>>> [  383.987744] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>>>> [  383.995898] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>>>> [  383.996249] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>>>> [  384.077562] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>>> [  384.077687] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>>> [  384.086571] Broadcom 43xx driver loaded [ Features: S ]
>>>> [  384.144620] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>>>> [  384.190831] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
>>>> [  395.097838] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [  395.098158] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [  397.667851] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [  397.668171] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [  403.940787] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [  403.941110] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [  405.366065] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>> [  405.366095] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>> [  405.389013] wlan0: authenticated
>>>> [  405.392814] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>>>> [  405.600498] wlan0: associate with da:b3:70:18:7c:14 (try 2/3)
>>>> [  405.808479] wlan0: associate with da:b3:70:18:7c:14 (try 3/3)
>>>> [  406.016481] wlan0: association with da:b3:70:18:7c:14 timed out
>>>> [  414.301216] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>> [  414.301245] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>> [  414.351544] wlan0: authenticated
>>>> [  414.403769] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>>>> [  414.422775] wlan0: RX AssocResp from da:b3:70:18:7c:14 (capab=0x1411 status=0 aid=25)
>>>> [  414.431879] wlan0: associated
>>>> [  415.272393] wlan0: Limiting TX power to 36 (36 - 0) dBm as advertised by da:b3:70:18:7c:14
>>>>
>>>> If there's anything further that would be useful here, let me know and I'd be happy to provide them.
>>>
>>> Seems the SDIO function driver b43-sdio does not print any error
>>> messages.  All the error paths in drivers/ssb/sdio.c print debug
>>> messages instead.
>>>
>>> I would suggest the following, which would limit messages to
>>> host mmc1 which is what is shown in message "b43-sdio mmc1:0001:1:
>>> Chip ID 14e4:4318"
>>>
>>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>>> index 860378bea557..2719b21783ad 100644
>>> --- a/drivers/mmc/core/core.c
>>> +++ b/drivers/mmc/core/core.c
>>> @@ -169,33 +169,33 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
>>>  	 * - The card was removed (...so just complete everything no matter
>>>  	 *   if there are errors or retries)
>>>  	 */
>>> -	if (!err || !cmd->retries || mmc_card_removed(host->card)) {
>>> +	if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
>>>  		mmc_should_fail_request(host, mrq);
>>>  
>>>  		if (!host->ongoing_mrq)
>>>  			led_trigger_event(host->led, LED_OFF);
>>>  
>>>  		if (mrq->sbc) {
>>> -			pr_debug("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
>>> +			pr_info("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
>>>  				mmc_hostname(host), mrq->sbc->opcode,
>>>  				mrq->sbc->error,
>>>  				mrq->sbc->resp[0], mrq->sbc->resp[1],
>>>  				mrq->sbc->resp[2], mrq->sbc->resp[3]);
>>>  		}
>>>  
>>> -		pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
>>> +		pr_info("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
>>>  			mmc_hostname(host), cmd->opcode, err,
>>>  			cmd->resp[0], cmd->resp[1],
>>>  			cmd->resp[2], cmd->resp[3]);
>>>  
>>>  		if (mrq->data) {
>>> -			pr_debug("%s:     %d bytes transferred: %d\n",
>>> +			pr_info("%s:     %d bytes transferred: %d\n",
>>>  				mmc_hostname(host),
>>>  				mrq->data->bytes_xfered, mrq->data->error);
>>>  		}
>>>  
>>>  		if (mrq->stop) {
>>> -			pr_debug("%s:     (CMD%u): %d: %08x %08x %08x %08x\n",
>>> +			pr_info("%s:     (CMD%u): %d: %08x %08x %08x %08x\n",
>>>  				mmc_hostname(host), mrq->stop->opcode,
>>>  				mrq->stop->error,
>>>  				mrq->stop->resp[0], mrq->stop->resp[1],
>> 
>> With these patches, I still get copious amounts of spam, but at least relevant
>> to the wifi card now.
>> Here's a hopefully useful snippet (it's just a lot of these, from what I could see),
>> from with my patches:
>> 
>> [  154.177276] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [  154.177297] mmc1:     4 bytes transferred: 0
>> <...>
>> [  186.707195] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [  186.707217] mmc1:     20 bytes transferred: 0
>> [  186.707358] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [  186.707382] mmc1:     384 bytes transferred: 0
>> [  186.707477] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [  186.707498] mmc1:     24 bytes transferred: 0
>> 
>> And the one from without is very similar, except I noticed this pattern:
>> [   85.942269] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [   85.942299] mmc1:     4 bytes transferred: 0
>> [   85.942523] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [   85.942555] mmc1:     4 bytes transferred: 0
>> [   85.944548] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [   85.944581] mmc1:     2 bytes transferred: 0
>> [   85.944777] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [   85.945160] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [   85.945187] mmc1:     2 bytes transferred: 0
>> ... occasionally, some of the requests don't have an "[x] bytes transferred: 0".
>> 
>> Hopefully these help.  I can get a capture of the entire log spam and
>> put it on on pastebin or something, if that would be more useful.
> 
> Need to know if there are any errors.  In "[x] bytes transferred: 0"
> messages, the "0" is the error code i.e. no error.  So you might be able
> to find errors like:
> 
> 	dmesg | grep 'bytes transferred' | grep -v 'bytes transferred: 0'
> 
> Also the debug patch could be tweaked to show errors only:
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 2719b21783ad..7b18fe6d5738 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -169,7 +169,7 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
>  	 * - The card was removed (...so just complete everything no matter
>  	 *   if there are errors or retries)
>  	 */
> -	if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
> +	if (host->index == 1 && (err || (mrq->data && mrq->data->error))) {
>  		mmc_should_fail_request(host, mrq);
>  
>  		if (!host->ongoing_mrq)
These patches were mildly revealing, I see this near the start of the logs:
[   32.222988] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
[   32.224789] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
[   32.227574] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[   32.227834] mmc1:     0 bytes transferred: -84
[   32.229615] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[   32.229876] mmc1:     0 bytes transferred: -84
[   32.230400] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[   32.230659] mmc1:     0 bytes transferred: -84
[   32.231173] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[   32.231476] mmc1:     0 bytes transferred: -84
[   32.233287] ssb: WARNING: Multiple ChipCommon found
[   32.234489] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
[   32.238533] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
[   32.264908] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
[   32.272565] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0

This occurs either with, or without, my patches.  However, no further
errors were logged.  Despite the lack of reported errors, the
functional behavior remained the same as I described earlier.

Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Adrian Hunter]

On 20/10/2025 10:53, Michael Garofalo wrote:
>> On 11/10/2025 00:16, Michael Garofalo wrote:
>>>> On 08/10/2025 04:10, Michael Garofalo wrote:
>>>>>> On 06/10/2025 12:28, Michael Garofalo wrote:
>>>>>>>> On 06/10/2025 10:35, Adrian Hunter wrote:
>>>>>>>>> On 06/10/2025 04:36, Michael Garofalo wrote:
>>>>>>>>>> This patch series adds a new bit to quirks2 for disabling the bounce
>>>>>>>>>> buffer.  On some hardware, this is required for proper operation.  An
>>>>>>>>>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>>>>>>>>>> "Hollywood" chipset.  Without this patch, the onboard Broadcom 4318
>>>>>>>>>> Wi-Fi fails to connect to any networks.
>>>>>>>>>
>>>>>>>>> The bounce buffer should not make any difference, so it is likely
>>>>>>>>> a different problem that gets hidden when the bounce buffer is not
>>>>>>>>> used.
>>>>>>>>>
>>>>>>>>>> Could you enable dynamic debug messages and show the messages
>>>>>>>>>> for the failing case?
>>>>>>>>>
>>>>>>>>> Actually will also need to see the messages in the "fixed" case
>>>>>>>>> to compare.
>>>>>>> I'm afraid I won't be able to provide those easily, at least not with the
>>>>>>> commands you've provided.  Since the rootfs is _also_ running from SD,
>>>>>>> turning on full MMC logs like this produces an obscene amount of noise
>>>>>>> from the storage, unrelated to the SDIO wireless.  It gets even worse with
>>>>>>> my original intention, which was to save the logs to SD Card, (since my USB
>>>>>>> Gecko serial console is rather flakey, and introduces corruption now and then),
>>>>>>> since it's now logging the writes of it's own logs in a permanent loop.
>>>>>>> If there's a way to narrow down the logs to specifically whatever portions
>>>>>>> you're interested in, and filter out the noise, I would happily provide it.
>>>>>>
>>>>>> Are there any error messages?
>>>>> If I drop the debug logs you mentioned so that I can actually see what's
>>>>> going on (they produce hundreds of lines / sec), here's what the Wi-Fi card
>>>>> actually reports with, vs without, MMC bounce buffers.  With bounce buffers on,
>>>>> it takes several tries to load the firmware, and it can't authenticate to any
>>>>> network.  I've tested and confirmed this effect on multiple consoles, across
>>>>> multiple reboots, on multiple Wi-Fi networks.  Meanwhile with MMC bounce buffers
>>>>> off, it's much more functional.
>>>>>
>>>>> Logs with MMC bounce buffers *on* (without my patches):
>>>>> [  168.492687] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>>>>> [  168.493516] ssb: Found chip with id 0x4710, rev 0x00 an package 0x00
>>>>> [  168.508519] ssb: WARNING: Multiple ChipCommon found
>>>>> [  168.510597] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>>>>> [  168.510886] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>>>>> [  168.530151] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>>>>> [  168.538447] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>>>>> [  168.719257] Broadcom 43xx driver loaded [ Features: S ]
>>>>> [  168.722231] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>>>> [  168.724613] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>>>> [  168.740666] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>>>>> [  168.762630] ieee80211 phy0: Slected rate control algorithm 'minstrel_ht'
>>>>> [  176.156693] b43-phy0: Loading OpenSource firmware version 410.31754
>>>>> [  176.157159] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>>> [  179.993008] b43-phy0: Loading OpenSource firmware version 410.31754
>>>>> [  179.994373] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>>> [  186.940346] b43-phy0: Loading OpenSource firmware version 410.31754
>>>>> [  186.942559] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>>> [  216.368668] b43-phy0: Loading OpenSource firmware version 410.31754
>>>>> [  216.369135] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>>> [  221.750016] b43-phy0: Loading OpenSource firmware version 410.31754
>>>>> [  221.757700] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>>> [  223.437731] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>>> [  223.437764] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>>> [  223.648472] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>>>> [  223.859770] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>>>> [  224.064469] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>>>> [  226.045361] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>>> [  226.045393] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>>> [  226.248488] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>>>> [  226.462378] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>>>> [  226.664487] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>>>> [  250.424168] b43-phy0: Loading OpenSource firmware version 410.31754
>>>>> [  250.425629] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>>> [  255.806790] b43-phy0: Loading OpenSource firmware version 410.31754
>>>>> [  255.807256] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>>> [  257.467380] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>>> [  257.467414] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>>> [  257.672475] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>>>> [  257.880474] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>>>> [  258.093974] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>>>> [  284.326415] b43-phy0: Loading OpenSource firmware version 410.31754
>>>>> [  284.326922] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>>> [  289.836233] b43-phy0: Loading OpenSource firmware version 410.31754
>>>>> [  289.837612] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>>> [  291.528250] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>>> [  291.528283] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>>> [  291.736473] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>>>> [  291.944482] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>>>> [  292.152470] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>>>> <keeps trying and failing forever....>
>>>>>
>>>>> Logs with MMC bounce buffers *off* (with my patches):
>>>>> [  383.974268] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>>>>> [  383.975824] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
>>>>> [  383.986645] ssb: WARNING: Multiple ChipCommon found
>>>>> [  383.987414] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>>>>> [  383.987744] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>>>>> [  383.995898] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>>>>> [  383.996249] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>>>>> [  384.077562] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>>>> [  384.077687] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>>>> [  384.086571] Broadcom 43xx driver loaded [ Features: S ]
>>>>> [  384.144620] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>>>>> [  384.190831] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
>>>>> [  395.097838] b43-phy0: Loading OpenSource firmware version 410.31754
>>>>> [  395.098158] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>>> [  397.667851] b43-phy0: Loading OpenSource firmware version 410.31754
>>>>> [  397.668171] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>>> [  403.940787] b43-phy0: Loading OpenSource firmware version 410.31754
>>>>> [  403.941110] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>>> [  405.366065] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>>> [  405.366095] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>>> [  405.389013] wlan0: authenticated
>>>>> [  405.392814] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>>>>> [  405.600498] wlan0: associate with da:b3:70:18:7c:14 (try 2/3)
>>>>> [  405.808479] wlan0: associate with da:b3:70:18:7c:14 (try 3/3)
>>>>> [  406.016481] wlan0: association with da:b3:70:18:7c:14 timed out
>>>>> [  414.301216] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>>> [  414.301245] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>>> [  414.351544] wlan0: authenticated
>>>>> [  414.403769] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>>>>> [  414.422775] wlan0: RX AssocResp from da:b3:70:18:7c:14 (capab=0x1411 status=0 aid=25)
>>>>> [  414.431879] wlan0: associated
>>>>> [  415.272393] wlan0: Limiting TX power to 36 (36 - 0) dBm as advertised by da:b3:70:18:7c:14
>>>>>
>>>>> If there's anything further that would be useful here, let me know and I'd be happy to provide them.
>>>>
>>>> Seems the SDIO function driver b43-sdio does not print any error
>>>> messages.  All the error paths in drivers/ssb/sdio.c print debug
>>>> messages instead.
>>>>
>>>> I would suggest the following, which would limit messages to
>>>> host mmc1 which is what is shown in message "b43-sdio mmc1:0001:1:
>>>> Chip ID 14e4:4318"
>>>>
>>>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>>>> index 860378bea557..2719b21783ad 100644
>>>> --- a/drivers/mmc/core/core.c
>>>> +++ b/drivers/mmc/core/core.c
>>>> @@ -169,33 +169,33 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
>>>>  	 * - The card was removed (...so just complete everything no matter
>>>>  	 *   if there are errors or retries)
>>>>  	 */
>>>> -	if (!err || !cmd->retries || mmc_card_removed(host->card)) {
>>>> +	if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
>>>>  		mmc_should_fail_request(host, mrq);
>>>>  
>>>>  		if (!host->ongoing_mrq)
>>>>  			led_trigger_event(host->led, LED_OFF);
>>>>  
>>>>  		if (mrq->sbc) {
>>>> -			pr_debug("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
>>>> +			pr_info("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
>>>>  				mmc_hostname(host), mrq->sbc->opcode,
>>>>  				mrq->sbc->error,
>>>>  				mrq->sbc->resp[0], mrq->sbc->resp[1],
>>>>  				mrq->sbc->resp[2], mrq->sbc->resp[3]);
>>>>  		}
>>>>  
>>>> -		pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
>>>> +		pr_info("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
>>>>  			mmc_hostname(host), cmd->opcode, err,
>>>>  			cmd->resp[0], cmd->resp[1],
>>>>  			cmd->resp[2], cmd->resp[3]);
>>>>  
>>>>  		if (mrq->data) {
>>>> -			pr_debug("%s:     %d bytes transferred: %d\n",
>>>> +			pr_info("%s:     %d bytes transferred: %d\n",
>>>>  				mmc_hostname(host),
>>>>  				mrq->data->bytes_xfered, mrq->data->error);
>>>>  		}
>>>>  
>>>>  		if (mrq->stop) {
>>>> -			pr_debug("%s:     (CMD%u): %d: %08x %08x %08x %08x\n",
>>>> +			pr_info("%s:     (CMD%u): %d: %08x %08x %08x %08x\n",
>>>>  				mmc_hostname(host), mrq->stop->opcode,
>>>>  				mrq->stop->error,
>>>>  				mrq->stop->resp[0], mrq->stop->resp[1],
>>>
>>> With these patches, I still get copious amounts of spam, but at least relevant
>>> to the wifi card now.
>>> Here's a hopefully useful snippet (it's just a lot of these, from what I could see),
>>> from with my patches:
>>>
>>> [  154.177276] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>>> [  154.177297] mmc1:     4 bytes transferred: 0
>>> <...>
>>> [  186.707195] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>>> [  186.707217] mmc1:     20 bytes transferred: 0
>>> [  186.707358] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>>> [  186.707382] mmc1:     384 bytes transferred: 0
>>> [  186.707477] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>>> [  186.707498] mmc1:     24 bytes transferred: 0
>>>
>>> And the one from without is very similar, except I noticed this pattern:
>>> [   85.942269] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>>> [   85.942299] mmc1:     4 bytes transferred: 0
>>> [   85.942523] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>>> [   85.942555] mmc1:     4 bytes transferred: 0
>>> [   85.944548] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>>> [   85.944581] mmc1:     2 bytes transferred: 0
>>> [   85.944777] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>>> [   85.945160] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>>> [   85.945187] mmc1:     2 bytes transferred: 0
>>> ... occasionally, some of the requests don't have an "[x] bytes transferred: 0".
>>>
>>> Hopefully these help.  I can get a capture of the entire log spam and
>>> put it on on pastebin or something, if that would be more useful.
>>
>> Need to know if there are any errors.  In "[x] bytes transferred: 0"
>> messages, the "0" is the error code i.e. no error.  So you might be able
>> to find errors like:
>>
>> 	dmesg | grep 'bytes transferred' | grep -v 'bytes transferred: 0'
>>
>> Also the debug patch could be tweaked to show errors only:
>>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index 2719b21783ad..7b18fe6d5738 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -169,7 +169,7 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
>>  	 * - The card was removed (...so just complete everything no matter
>>  	 *   if there are errors or retries)
>>  	 */
>> -	if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
>> +	if (host->index == 1 && (err || (mrq->data && mrq->data->error))) {
>>  		mmc_should_fail_request(host, mrq);
>>  
>>  		if (!host->ongoing_mrq)
> These patches were mildly revealing, I see this near the start of the logs:
> [   32.222988] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> [   32.224789] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
> [   32.227574] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [   32.227834] mmc1:     0 bytes transferred: -84
> [   32.229615] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [   32.229876] mmc1:     0 bytes transferred: -84
> [   32.230400] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [   32.230659] mmc1:     0 bytes transferred: -84
> [   32.231173] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [   32.231476] mmc1:     0 bytes transferred: -84
> [   32.233287] ssb: WARNING: Multiple ChipCommon found
> [   32.234489] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
> [   32.238533] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
> [   32.264908] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
> [   32.272565] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
> 
> This occurs either with, or without, my patches.  However, no further
> errors were logged.  Despite the lack of reported errors, the
> functional behavior remained the same as I described earlier.

The absence of mmc errors narrows the possibilities.  I notice that
sdhci-of-hlwd.c is using:

	.quirks = SDHCI_QUIRK_32BIT_DMA_ADDR |
		  SDHCI_QUIRK_32BIT_DMA_SIZE,

so there could be some conflict with using PIO sometimes and
the bounce buffer at others.

Also the bounce buffer uses slightly different DMA APIs,
and was designed for the block driver not SDIO.

Adding Linus Walleij who wrote the bounce buffer code for
his comments.

Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

[Linus Walleij]

On Fri, Oct 24, 2025 at 7:37 AM Adrian Hunter <adrian.hunter@intel.com> wrote:

> > These patches were mildly revealing, I see this near the start of the logs:
> > [   32.222988] b43-sdio mmc1:0001:1: Chip ID 14e4:4318

B43 WLAN eh? That driver is heavily bitrotted.

Anyways b43 does:

#define B43_SDIO_BLOCK_SIZE    64    /* rx fifo max size in bytes */

sdio_set_block_size(func, B43_SDIO_BLOCK_SIZE);

So that is an indication it does not want anything bigger than
that in it's FIFO.

It does this by setting blksize down to 64 and then sending
(probably) a train of sg_list:ed requests that the bound buffer
will merge into a contiguous request much bigger than 64
bytes to speed things up.

But I don't think the bounce buffer has proper SDIO minimum
block size awareness. It should simply step out of the way when
we do SDIO.

I will send a patch you can test.

Yours,
Linus Walleij