From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Avri Altman <Avri.Altman@sandisk.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Brown <broonie@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH v1 1/1] mmc: core: Handle undervoltage events and register regulator notifiers
Date: Thu, 13 Feb 2025 12:09:46 +0100 [thread overview]
Message-ID: <Z63S-nQKwPws2-C3@pengutronix.de> (raw)
In-Reply-To: <PH7PR16MB619609C650452062D6BC2385E5FF2@PH7PR16MB6196.namprd16.prod.outlook.com>
On Thu, Feb 13, 2025 at 10:14:00AM +0000, Avri Altman wrote:
> > Extend the MMC core to handle undervoltage events by implementing
> > infrastructure to notify the MMC bus about voltage drops.
> >
> > Background & Decision at LPC24:
> >
> > This solution was proposed and refined during LPC24 in the talk "Graceful
> > Under Pressure: Prioritizing Shutdown to Protect Your Data in Embedded
> > Systems" which aimed to address how Linux should handle power fluctuations
> > in embedded devices to prevent data corruption or storage damage.
> >
> > At the time, multiple possible solutions were considered:
> >
> > 1. Triggering a system-wide suspend or shutdown: when undervoltage is
> > detected, with device-specific prioritization to ensure critical
> > components shut down first.
> > - This approach was disliked by Greg Kroah-Hartman, as it introduced
> > complexity and was not suitable for all use cases.
> >
> > 2. Notifying relevant devices through the regulator framework: to allow
> > graceful per-device handling.
> > - This approach was agreed upon as the most acceptable: by participants
> > in the discussion, including Greg Kroah-Hartman, Mark Brown,
> > and Rafael J. Wysocki.
> > - This patch implements that decision by integrating undervoltage
> > handling into the MMC subsystem.
> >
> > This patch was tested on iMX8MP based system with SDHCI controller.
> Has it been considered, to rely on user-space and not the kernel to handle
> those extreme conditions?
> E.g. a pollable sysfs that would be monitored by select(), poll(), etc.
> As Android might use?
Yes, the advantage of solving this in the kernel is:
- The regulator framework already provides all the necessary components,
including event support.
- The MMC framework already supports regulators, making the implementation
straightforward.
- This approach works even if userspace is not ready at boot time.
On the other hand, you are right that a userspace implementation would offer
more flexibility. However, I believe this can be built as an extension of the
current implementation. The regulator framework supports Netlink notifications
to userspace, eliminating the need for sysfs polling. The MMC framework would
also require a sysfs interface to force a quick shutdown - if such an interface
does not already exist - and a filter for regulator notifications to ignore
undervoltage events when they are handled in userspace.
Best Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
prev parent reply other threads:[~2025-02-13 11:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 13:24 [PATCH v1 1/1] mmc: core: Handle undervoltage events and register regulator notifiers Oleksij Rempel
2025-02-12 23:47 ` Christian Loehle
2025-02-13 8:57 ` Oleksij Rempel
2025-02-13 11:13 ` Christian Loehle
2025-02-13 10:14 ` Avri Altman
2025-02-13 11:09 ` Oleksij Rempel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z63S-nQKwPws2-C3@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=Avri.Altman@sandisk.com \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox