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: <20250411130354.dc3sv3e7ruekkhkp@hiago-nb>
Date: Fri, 11 Apr 2025 10:03:54 -0300
From: Hiago De Franco <hiagofranco@...il.com>
To: Judith Mendez <jm@...com>
Cc: Adrian Hunter <adrian.hunter@...el.com>,
	Ulf Hansson <ulf.hansson@...aro.org>, linux-mmc@...r.kernel.org,
	linux-kernel@...r.kernel.org, Josua Mayer <josua@...id-run.com>,
	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 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?

Cheers,
Hiago.