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: <f4100ee2c655df5394322bb167f62dfd0a6587b8.camel@siemens.com>
Date: Thu, 8 Jan 2026 17:54:21 +0000
From: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
To: "nm@...com" <nm@...com>, "alexander.sverdlin@...il.com"
	<alexander.sverdlin@...il.com>
CC: "d-gole@...com" <d-gole@...com>, "sebin.francis@...com"
	<sebin.francis@...com>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "a-kaur@...com" <a-kaur@...com>,
	"k-willis@...com" <k-willis@...com>, "vigneshr@...com" <vigneshr@...com>,
	"vishalm@...com" <vishalm@...com>, "khilman@...libre.com"
	<khilman@...libre.com>, "msp@...libre.com" <msp@...libre.com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

Hi Nishanth!

> > > > I think we would need to discuss this with TI via our FAE, because the change
> > > > in question has both been discussed with former FAE and the technical team
> > > > behind, and adopted in TI SDK.
> > > > 
> > > > Or have you already discused this with corresponding TI HW team?
> > > > 
> > > > Which hardware is affected, is it the official SK-AM62A-LP?
> > > > Is MMC2 the SD-card?
> > > 
> > > I only tested my am62a board on u-boot v2026.01. It is a SK-AM62A-LP.
> > > MMC2 is the SD-card and mmc1 in the devicetree.
> > 
> > just wanted to let you know, I was able to reproduce the problems with SD
> > card access via MMC2 under Linux on AM623 with ST enabled.
> > 
> > We will seek clarification from TI on why this happens, which peripherals
> > are affected and what should be the course of actions.
> 
> 
> I have passed this up the chain here at TI. What confuses the heck out

Great, thanks Nishanth!

> of me is this: from an internal email chain I am privy to, i am being
> told that "the ST_EN bit in every PADCONFIG register should never be
> changed from its power-on default state of 0b1" and the fact that Linux

that's the info we've got from FAE initially and...

> kernel has been stable with the setting for a long period, So I am

... realized that Linux actually did the exact opposite of it since the first K3s
(AM65) and though "Ouch!"

That's how I quickly came up with 5b272127884b and though "finally we are safe!"

And "stable" is relative, we've found it out because GPIOs did produce
spurious interrupts, it's just that most of the drivers can handle it
gracefully. Except interrupt event counters...

> confused why U-Boot would show this instability.. I don't have answers
> at the moment. until we clarify the reasoning, I am going to have to
> hold off this given that kernel behavior has not regressed that I am
> aware of.

Indeed, I've reproduced it with AM623 in Linux [1], even though it's not
TI evaluation board, it's our HW. We do have other HW design where the
problem doesn't manifest itself, so ST seems to put MMC on the edge somehow.

I can try to retest TI AM625 based EKs at some point, but it could take
some days on my side...

[1] https://lore.kernel.org/all/6c90102537c3e3f1712538ca0b165cd54d71d8c2.camel@gmail.com/

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ