Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Date:   Thu, 7 Dec 2023 18:49:34 +0000
From:   Mark Brown <broonie@kernel.org>
To:     Matti Vaittinen <mazziesaccount@gmail.com>
Cc:     Naresh Solanki <naresh.solanki@9elements.com>,
        Liam Girdwood <lgirdwood@gmail.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] regulator: event: Add regulator netlink event support
Message-ID: <1ddd9fb6-a746-423b-ac2f-63cf4627846c@sirena.org.uk>
References: <20231205105207.1262928-1-naresh.solanki@9elements.com>
 <46b1d303-8104-4298-bd43-a649634f5393@gmail.com>
 <CABqG17jwAw6zqy9FLtZ3ppwLT+3fAQ21bGfMr4Xt5eTDm-jQMw@mail.gmail.com>
 <70cbf708-72a6-4413-8181-99441f676d57@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="QsttYYoTueuG4VIU"
Content-Disposition: inline
In-Reply-To: <70cbf708-72a6-4413-8181-99441f676d57@gmail.com>
Precedence: bulk


--QsttYYoTueuG4VIU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Dec 07, 2023 at 03:29:18PM +0200, Matti Vaittinen wrote:
> On 12/7/23 14:39, Naresh Solanki wrote:

> > When I wrote the code, I kept in mind to make sure to receive all events
> > from regulators so that userspace application (in my case BMC
> > application which does power sequence) has regulator events information.
> > Hence I assumed that its upto userspace application to decide on corrective
> > action based on events of interest.

> I do also think it probably is. However, do you see cases where the action
> to be taken is a result of a hardware-design. Maybe in such cases the
> information like "critical under-voltage, please shut down the system" could
> originate from the board designer's drawing-table, end up in board
> device-tree, be read by the drivers/kernel and then be sent to a user-land
> with suitable severity information indicating that an action should be
> taken. I am just speculating if we could have a more generic user-space
> application which took care of this instead of always writing a
> system-specific user-space application.

That definitely seems doable (see also the discussion about emergency
shutdown) and also for other applications like providing a UI
representing what's going on.  I can imagine figuring out which
regulators supply a SD card slot and looking for errors from them for
example.  BMCs might have similar applications.

> Still, as I wrote, I am not sure this is too important. I don't know if any
> 'action' decisions can be done based on currently existing ERROR/WARNING
> severities - and the netlink message API can be later extended by adding new
> attributes. So, please treat my message just as a fuel for thought - I'm
> sure you have better insight to the use of these notifications than I do :)

It does feel like it's going to be up to the system/application how
severe an individual error will be.

> > Current implementation is such that all events will be sent.
> > But I agree with you that it is not something desired as sometimes
> > application might not be interested in all events.
> > Also I'm not sure on multicast group, as currently only one group
> > exist for regulator event & how adding additional group would help.

> Again, this might be my delusion :) Once upon a time I wrote a (downstream)
> netlink interface for sending certain specific purpose measurement results
> to the user-space. I have a faint memory from those days that it was
> possible to specify the multicast groups of interest at socket bind() -
> time. In this way "multiplexing" the messages would be done by kernel and
> user-space code could only listen the messages of interest? Maybe there are
> caveats I am not aware of though.

I guess that'd overlap with the use case above with UI for something
like a SD card, filtering on the regulator.

> Yes. These were my points to consider - but you / Mark are free to use your
> judgement on if this makes any sense or not. I am not confident enough these
> are necessary "features" to really push for them.

It does seem like they could be useful.

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

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

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmVyE70ACgkQJNaLcl1U
h9CmYwgAhsAYbshLwEvIBqzziKs1VvOdFbDHv5/LVkYc+fVUl5ikHskpeonhfvp9
ld+XTmPRnpAbP81h4TfR4YeZqDjWECed4pkzuBi2SBmzKlCL0JxrLESjX46AsCpP
PJrw22l1RjCvfMccdftL2dOhtv3aG+uiQx+l6gggaZpbRPzIUV1SczyCq/PF9JKv
iFCf2AWbbqXG0Y9sGueL3nilEO5ca0bWrJAVG4iKdch3QFEhiYCJe5OVLskFwSp5
WsBRZevLIEMCNGa2uno/1QcU5dXqk0WgjdsqDSrTxgZMpVjlrKtovUGz4KsCrZ+E
vrO7tIMILA96WfjW5Nq7O2bYkSfDUg==
=FEuo
-----END PGP SIGNATURE-----

--QsttYYoTueuG4VIU--