linux-kernel - Re: [PATCH v4 0/2] Add SDHCI_QUIRK2_SUPPRESS_V1P8

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] [day] [month] [year] [list]

Message-ID: <CAPDyKFpMo3a_MZuD1q+JFEa4VqHeoJ-SegviJfd322jkV29+Pw@mail.gmail.com>
Date: Wed, 7 May 2025 12:14:47 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: "Mendez, Judith" <jm@...com>
Cc: Adrian Hunter <adrian.hunter@...el.com>, Josua Mayer <josua@...id-run.com>, 
	linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Nishanth Menon <nm@...com>, Francesco Dolcini <francesco@...cini.it>, 
	Hiago De Franco <hiagofranco@...il.com>, Moteen Shah <m-shah@...com>
Subject: Re: [PATCH v4 0/2] Add SDHCI_QUIRK2_SUPPRESS_V1P8_ENA

On Mon, 5 May 2025 at 23:24, Mendez, Judith <jm@...com> wrote:
>
> Hi all,
>
> On 4/24/2025 1:00 PM, Judith Mendez wrote:
> > There are MMC boot failures seen with V1P8_SIGNAL_ENA on Kingston eMMC and
> > Microcenter/Patriot SD cards on am62* Sitara K3 boards due to the HS200
> > initialization sequence involving V1P8_SIGNAL_ENA. Since V1P8_SIGNAL_ENA
> > is optional for eMMC and only affects timing for host controllers using
> > ti,am62-sdhci compatible so far, add a new platform data structure for am62
> > compatible and append the new SDHCI_QUIRK2_SUPPRESS_V1P8_ENA quirk.
> >
> > This fix was previously merged in the kernel, but was reverted due
> > to the "heuristics for enabling the quirk"[0]. This issue is adressed
> > in this patch series by adding the quirk based on compatible string,
> > ensuring the quirk is never applied to devices with internal LDOs, then
> > V1P8_SIGNAL_ENA also has a voltage component tied to it.
>
> Gentle ping on this, are there any comments or any issues with this
> type of implementation?

It looks reasonable to me. Although, in general I think we are trying
to avoid adding new sdhci quirks, perhaps there are good reasons to do
it in this case.

I am deferring to Adrian to make the decision.

Kind regards
Uffe