Message-ID: <d7be077e-9972-4364-9804-201c19757480@intel.com>
Date: Fri, 24 Oct 2025 08:36:54 +0300
From: Adrian Hunter <adrian.hunter@...el.com>
To: Michael Garofalo <officialtechflashyt@...il.com>, linus walleij
	<linus.walleij@...aro.org>
CC: <linux-kernel@...r.kernel.org>, <linux-mmc@...r.kernel.org>,
	<ulf.hansson@...aro.org>
Subject: Re: [PATCH 0/2] mmc: sdhci: add quirk to disable bounce buffer

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.

Powered by blists - more mailing lists