Message-ID: <1ddd9fb6-a746-423b-ac2f-63cf4627846c@sirena.org.uk>
Date:   Thu, 7 Dec 2023 18:49:34 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Matti Vaittinen <mazziesaccount@...il.com>
Cc:     Naresh Solanki <naresh.solanki@...ements.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] regulator: event: Add regulator netlink event support

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists