linux-kernel - Re: [RFC PATCH V2 2/2] mmc: allow card to disable tuning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4030ee60-b607-4ddf-99d9-5348a741f7d5@intel.com>
Date: Fri, 7 Mar 2025 20:44:17 +0200
From: Adrian Hunter <adrian.hunter@...el.com>
To: Erick Shepherd <erick.shepherd@...com>
CC: <andy-ld.lu@...iatek.com>, <avri.altman@....com>,
	<cw9316.lee@...sung.com>, <dsimic@...jaro.org>, <keita.aihara@...y.com>,
	<linux-kernel@...r.kernel.org>, <linux-mmc@...r.kernel.org>,
	<quic_jjohnson@...cinc.com>, <ricardo@...liere.net>,
	<ulf.hansson@...aro.org>, <victor.shih@...esyslogic.com.tw>,
	<wsa+renesas@...g-engineering.com>
Subject: Re: [RFC PATCH V2 2/2] mmc: allow card to disable tuning

On 7/03/25 19:45, Erick Shepherd wrote:
>> Sorry for the slow reply.
> 
>> I would expect if there was a general problem with DDR50 SD cards,
>> it would have come to light before now.
> 
>> Does the card work with any other host controllers with linux?
> 
>> If it is specific to a particular kind of card, a card quirk
>> could be added, say MMC_QUIRK_BROKEN_DDR50_TUNING
> 
> No worries. I have not tested this with other host controllers but
> can try to get something set up. This issue has only appeared on
> one particular SD card model for us so I would not be surprised if
> the I/O errors we see on subsequent tune requests are specific to this
> card. I can put together a solution using the card quirk you suggested
> if you think that is the best way forward.
> 
> My fix is currently spread across two commits, one to return the error
> code thrown by the tune request timing out, which prevents the card from
> retuning, and this one that prevents the initial card tuning if it has
> already failed. Should both parts be controlled by the new card quirk?

Does it tuning at all?  Maybe MMC_QUIRK_NO_UHS_DDR50_TUNING is a better
name, then at the top of mmc_execute_tuning()

	if ((card->quirks & MMC_QUIRK_NO_UHS_DDR50_TUNING) &&
	    host->ios->timing == MMC_TIMING_UHS_DDR50)
		return 0;