Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
Date:   Thu, 12 Oct 2023 10:08:40 +0300
From:   Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
To:     Mark Brown <broonie@kernel.org>
Cc:     Oleksij Rempel <o.rempel@pengutronix.de>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>, kernel@pengutronix.de,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
        Naresh Solanki <naresh.solanki@9elements.com>,
        zev@bewilderbeest.net, Sebastian Reichel <sre@kernel.org>,
        linux-pm@vger.kernel.org
Subject: Re: [PATCH v1 3/3] regulator: fixed: forward under-voltage events
Message-ID: <ZSebeJKa0sEzNzP4@dc78bmyyyyyyyyyyyyydt-3.rev.dnainternet.fi>
References: <20231010085906.3440452-1-o.rempel@pengutronix.de>
 <20231010085906.3440452-3-o.rempel@pengutronix.de>
 <5e51792a-cc93-4364-a51b-c2b116d89369@sirena.org.uk>
 <20231010125531.GA3268051@pengutronix.de>
 <c2ee404d-d07f-42c6-b5ba-41659773e8eb@sirena.org.uk>
 <20231011075931.GA3305420@pengutronix.de>
 <2d14fd22-c37b-4c15-a2ea-a2fd2c201adb@sirena.org.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="zTBIn7qXME7IwVru"
Content-Disposition: inline
In-Reply-To: <2d14fd22-c37b-4c15-a2ea-a2fd2c201adb@sirena.org.uk>
Precedence: bulk


--zTBIn7qXME7IwVru
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 11, 2023 at 12:38:19PM +0100, Mark Brown wrote:
> On Wed, Oct 11, 2023 at 09:59:31AM +0200, Oleksij Rempel wrote:
>=20
> > Configuration through the device tree and kernel defaults is preferable.
> > For instance, having a default kernel governor that doesn=E2=80=99t req=
uire user
> > space configuration aligns with the project=E2=80=99s objectives.
>=20
> That's policy though...
>=20
> >=20
> > > For the regulator itself we probably want a way to identify regulators
> > > as being system critical so they start notifying.  It would be tempti=
ng

Can the "criticality" could be determined by the severity (ERROR vs WARNING=
)?

> > > to just do that by default but that would likely cause some issues for
> > > example with regulators for things like SD cards which are more likely
> > > to get hardware problems that don't comprimise the entire system.  We

"comprimise the entire system" sounds (to my ears) exactly the
difference between WARNING and ERROR notifications.

> > > could do that with DT, either a property or some sort of runtime
> > > consumer, but it might be better to have a control in sysfs that
> > > userspace can turn on?  OTOH the ability do something about this depe=
nds
> > > on specific hardware design...
> > >=20
> > > I've copied in Sebastian since this sounds like the sort of thing that
> > > power supplies might have some kind of handling for, or at least if we
> > > need to add something we should make it so that the power supplies can
> > > be joined up to it.  I do see temperature and capacity alerts in the
> > > sysfs ABI for power supplies, but nothing for voltage.
> >=20
> > Thank you for pointing towards the power supply framework. Given the ha=
rdware
> > design of my project, I can envision mapping the following states and
> > properties within this framework:
>=20
> There's also hw_failure_emergency_poweroff() which looks like exactly
> what you're trying to trigger here.

There is already a path from regulator notification handling to the
hw_failure_emergency_poweroff() - although only when handling the IRQs
fail and this failure is marked as fatal.

> > Considering the above mapping, my initial step would be to create a sim=
ple
> > regulator coupled (if regulator is still needed in this casr) with a De=
vice
> > Tree (DT) based power supply driver.  This setup would align with the e=
xisting
> > power supply framework, with a notable extension being the system-wide
> > notification for emergency shutdown upon under-voltage detection.
>=20
> It sounds like this is actually a regulator regardless of if it also
> appears via some other API.

I wonder if it would make sense to add a 'protector' in regulator core.
The 'protector' could register to listen the notifications from those
regulators which have some
'regulator-fatal-notifications =3D <list of notifications>;' -property
defined in device-tree.

In my eyes the device-tree is correct place for this information
because whether an "anomaly" in regulator output compromises the system
is a property of hardware.

Yours,
	-- Matti

--=20
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =3D]=20

--zTBIn7qXME7IwVru
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEIx+f8wZb28fLKEhTeFA3/03aocUFAmUnm20ACgkQeFA3/03a
ocWoBAgAvt694sDu7d/r9CyhNbd/uDFnCTQ6LVK2CakUfO4JsjW/x+Pe1YrvRlQc
EZkpcaH0TKhQEc1jS+E8pYuX9YVjmAmmRJKQVe3PhK3lRc8WwqX2iWgALbHI0A/b
GudY8ngHDk1ShNLZfwMFLRghRSc+kBIEs/ZnsWG0dJDr2l/Tr6n6uAtgkWZC3i6X
vuAoq7g9NQRXBD0kBctmmWJfWcUSc0tFPN+fAqvQuUERms8opu95YFpIpBuFx8Hi
yw2JiMPrwVOrHeIb5ZhJuVho41BcmnFcU2bCKYXdrXfS1QX5b3mbUHdC3nrBfI0V
HtUJ12Ohl3YkW1euY/4rfDrL7lYHTw==
=JFJH
-----END PGP SIGNATURE-----

--zTBIn7qXME7IwVru--