linux-kernel - Re: [PATCH 0/2] Fix V1P8_SIGNAL_ENA and HIGH_SPEED

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: <d8e45e50-f0eb-41d0-9c50-56147eaf262a@ti.com>
Date: Fri, 11 Apr 2025 11:37:14 -0500
From: Judith Mendez <jm@...com>
To: Hiago De Franco <hiagofranco@...il.com>, Josua Mayer <josua@...id-run.com>
CC: Adrian Hunter <adrian.hunter@...el.com>,
        Ulf Hansson
	<ulf.hansson@...aro.org>, <linux-mmc@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, Moteen Shah <m-shah@...com>,
        Hiago De Franco
	<hiago.franco@...adex.com>
Subject: Re: [PATCH 0/2] Fix V1P8_SIGNAL_ENA and HIGH_SPEED_ENA

Hi Hiago,

On 4/11/25 8:03 AM, Hiago De Franco wrote:
> Hi Judith,
> 
> On Mon, Apr 07, 2025 at 05:27:00PM -0500, Judith Mendez wrote:
>> For all TI devices, timing was closed For Legacy and HS modes in
>> half cycle timing, where data is launched on the negative edge of
>> clock and latched on the following positive edge of clock. The
>> switch to full cycle timing happens when any of HIGH_SPEED_ENA,
>> V1P8_SIGNAL_ENA, or UHS_MODE_SELECT is set.
>>
>> Currently HIGH_SPEED_ENA is set for HS modes and violates timing
>> requirements for TI devices so add a .set_hs_ena callback in
>> sdhci_am654 driver so that HIGH_SPEED_ENA is not set for this mode.
>>
>> There are eMMC boot failures seen with V1P8_SIGNAL_ENA with a
>> specific Kingston eMMC due to the sequencing when enumerating to
>> HS200 mode. Since V1P8_SIGNAL_ENA is optional for eMMC, do not
>> set V1P8_SIGNAL_ENA be default. This fix was previously merged in
>> the kernel, but was reverted due to the "heuristics for enabling
>> the quirk"[0]. The new implementation applies the quirk based-off of
>> bus width, which should not be an issue since there is no internal
>> LDO for MMC0 8bit wide interface and hence V1P8_SIGNAL_ENA should only
>> effect timing for MMC0 interface.
>>
>> [0] https://lore.kernel.org/linux-mmc/20250127-am654-mmc-regression-v2-1-9bb39fb12810@solid-run.com/
>>
>> Judith Mendez (2):
>>    PENDING: mmc: sdhci*: Add set_hs_ena to sdhci_ops
>>    mmc: sdhci_am654: Add sdhci_am654_start_signal_voltage_switch
>>
>>   drivers/mmc/host/sdhci.c       | 55 +++++++++++++++++++++-------------
>>   drivers/mmc/host/sdhci.h       |  2 ++
>>   drivers/mmc/host/sdhci_am654.c | 48 +++++++++++++++++++++++++++++
>>   3 files changed, 85 insertions(+), 20 deletions(-)
>>
>> -- 
>> 2.49.0
>>
> 
> Thanks for the patches. We are currently experiencing this issue on the
> AM62 Solo SoC (hardware: Toradex Verdin AM62 Solo 512 MB), with the
> latest kernel 6.15-rc1. I tested your patches (added both on top of
> 6.15-rc1) and I can still see the issue, when the kernel boots:
> 
> root@...din-am62-15412807:~# dmesg | grep -i mmc1
> [    1.912123] mmc1: CQHCI version 5.10
> [    1.985262] mmc1: SDHCI controller on fa00000.mmc [fa00000.mmc] using ADMA 64-bit
> [    2.186954] mmc1: error -110 whilst initialising SD card
> [    2.620625] mmc1: error -110 whilst initialising SD card
> [    2.997642] mmc1: error -110 whilst initialising SD card
> [    3.337071] mmc1: error -110 whilst initialising SD card
> 
> This does not happen if I use commit 941a7abd4666 ("mmc: sdhci_am654:
> Add sdhci_am654_start_signal_voltage_switch"), as you described.
> 
> Is there anything I missing or should test to make it work?

The reason that patches fixes SD init for you is because in original 
patch, quirk was applied for both SD and eMMC with the exception of SD 
for am64x SoC. This patch only applies the quirk for eMMC.

We cannot use the original implementation because the logic applying the 
quirk is based off of vmmc/vqmmc nodes in DT. The assumption was that 
am64x based boards will only have vmmc node since there is an internal 
LDO that is used to switch IO signal voltage instead of vqmmc. However, 
SolidRun HimmingBoard-T board has a different implementation on voltage 
regulator nodes in DT and the quirk applied to them as well and breaks 
their SD boot. So we now only apply the quirk for eMMC. Without this 
quirk applied to SD, am62x SD will continue having some stability issues.

~ Judith