linux-kernel - Re: [RFC] mmc: meson-gx-mmc: add delay during poweroff

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: <CAPDyKFo_1KHLw0_OE2ppJnA1TKmmd4EKjMKcSqOdGo91bMgMTw@mail.gmail.com>
Date: Thu, 3 Jul 2025 13:59:02 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Da Xue <da@...re.computer>
Cc: Martin Blumenstingl <martin.blumenstingl@...glemail.com>, 
	Jerome Brunet <jbrunet@...libre.com>, Anand Moon <linux.amoon@...il.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Kevin Hilman <khilman@...libre.com>, 
	linux-mmc@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] mmc: meson-gx-mmc: add delay during poweroff

On Wed, 2 Jul 2025 at 23:05, Da Xue <da@...re.computer> wrote:
>
> On Wed, Jul 2, 2025 at 4:57 PM Martin Blumenstingl
> <martin.blumenstingl@...glemail.com> wrote:
> >
> > On Wed, Jul 2, 2025 at 9:07 PM Da Xue <da@...re.computer> wrote:
> > >
> > > On Wed, Jul 2, 2025 at 2:40 PM Martin Blumenstingl
> > > <martin.blumenstingl@...glemail.com> wrote:
> > > >
> > > > On Wed, Jul 2, 2025 at 7:22 PM Da Xue <da@...re.computer> wrote:
> > > > >
> > > > > On Wed, Jul 2, 2025 at 1:07 PM Jerome Brunet <jbrunet@...libre.com> wrote:
> > > > > ...
> > > > > > If, as the description suggest, the regulator framework somehow ignore
> > > > > > the timing set in DT, maybe this is what needs to be checked ?
> > > > >
> > > > > The regulator framework only cares about timing for regulator on.
> > > > > Regulator off just turns off the regulator and returns without delay.
> > > > There's an exception to this: gpio-regulators without an enable-gpios
> > > > property. My understanding is that regulator_disable() is a no-op in
> > > > that case (meson_mmc_set_ios() even has a comment above the
> > > > switch/case statement), see [0].
> > > >
> > > > > The code makes incorrect assumptions. Then the kernel resets the board
> > > > > without having enough time.
> > > > Can you please name the board you're testing? I'm worried that I'll be
> > > > looking at one .dts but you're looking at another one.
> > >
> > > https://github.com/libre-computer-project/libretech-linux/blob/master/arch/arm64/boot/dts/amlogic/meson-libretech-cottonwood.dtsi#L481
> > >
> > > vcc_card is a gpio regulator that gets toggled on->off->on.
> > Thanks, that clears things up as I was indeed looking at a gpio
> > regulator while this is a fixed regulator!
> >
> > > I traced the regulator framework a few weeks ago and forgot the final
> > > regulator disable function call, but that call basically returned
> > > immediately while the regulator-enable function complement had delays
> > > implemented.
> > Yep, for fixed regulators there's an "off-on-delay-us" device-tree
> > property (which translates to "off_on_delay" in the code).
> > Its implementation is smart enough to not waste time by adding delays
> > at runtime by implementing: on -> off + remember time -> wait
> > remaining time + on (meaning: if there was enough time between off and
> > the second on there's no additional wait) [0]. On system shutdown it
> > will not add any delay unfortunately (where Linux loses control over
> > time-keeping), meaning we can end up with too little waiting time.
>
> Yes, this is evident on quite a few Amlogic boards but occurred rarely
> enough that it can be overlooked but never-the-less should be
> addressed.
>
> On our SM1 board, this occurs more often than not. With this patch, we
> can reboot the loop indefinitely.

Even if this patch fixes the problem, it doesn't really seem like the
correct solution to me.

Would you mind trying to extend the regulator subsystem to deal with
this instead? Feel free to keep me in the loop if you post something
there.

>
> >
> > Also my understanding is that it's not something that can be fixed in
> > u-boot or TF-A. This is because bootrom already has trouble reading
> > the next stage from an SD card (which is a valid boot media).
>
> Correct, not fixable in TF-A or u-boot.
>
> >
> >
> > [0] https://elixir.bootlin.com/linux/v6.15/source/drivers/regulator/core.c#L2754

Kind regards
Uffe