Message-ID: <d6a3ca82-7245-45e1-b8ff-a9970671b04f@sirena.org.uk>
Date:   Thu, 6 Apr 2023 14:43:03 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Matti Vaittinen <mazziesaccount@...il.com>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Naresh Solanki <naresh.solanki@...ements.com>,
        linux-hwmon@...r.kernel.org, Jean Delvare <jdelvare@...e.com>,
        Patrick Rudolph <patrick.rudolph@...ements.com>,
        linux-kernel@...r.kernel.org, Sascha Hauer <sha@...gutronix.de>,
        jerome Neanne <jneanne@...libre.com>,
        "Mutanen, Mikko" <Mikko.Mutanen@...rohmeurope.com>
Subject: Re: [PATCH v2 2/3] hwmon: (pmbus/core): Add regulator event support

On Thu, Apr 06, 2023 at 11:00:02AM +0300, Matti Vaittinen wrote:
> ke 5. huhtik. 2023 klo 18.19 Mark Brown (broonie@...nel.org) kirjoitti:
> > On Wed, Apr 05, 2023 at 07:18:32AM -0700, Guenter Roeck wrote:

> > > Same situation. I though a regulator driver would notify the regulator subsystem

> I think this notification is not processed by the regulator subsystem.
> It is just delivered to the consumer driver(s) who have subscribed the
> notifications.

Right.  The hardware might autonomously do something but there's nothing
in the framework which will take any action.

> > The theory is that if a consumer detects that the device it's
> > controlling has bad power then it can take corrective action if there's
> > some specification mandated error handling (for something like a
> > standard bus) or risk of hardware damage.

> The problem I see here is that, if the error information itself
> (severity + notification type) does not 'classify' the error handling
> - then I don't see how any consumers can do handling unless they are
> targeted to one specific system only. My original thinking has been
> that ERROR level notifications are sent only when HW is no longer
> operable - and consumers are expected to do what-ever protective
> actions they can, including turning off the faulty regulator. That is
> why I originally asked about handling the PMBUS errors.

TBH I think if you're at the point where you've got regulator hardware
flagging problems in most system designs there's serious problems, I'm
not sure how likely it is that it's worth trying to classify the errors.
Perhaps there's some systems that frequently flag low level errors
though.

> > It can also try to avoid
> > interacting with hardware if that might not work.

> It'd be great to have documentation / specification for sending and/or
> handling the regulator events. I don't think we currently have such.
> As far as I understand, the notifications can be picked up by all
> consumers of a regulator. I am a bit worried about:
> a) Situations where notification handlers 'collide' by doing 'actions'
> which are unexpected by other handlers

I'm not sure what you're expecting there?  A device working with itself
shouldn't disrupt any other users.

> b) Situations where different notification senders send similar
> severity-level notifications for faults expecting different types of
> handling.

Like I say I'm not sure how much practical difference it makes to think
too hard about differentiating the errors.

> Or, is it so that no "generic handling" of these errors is to be
> expected? Eg, consumers who implement any handling must always be
> targeted to a very specific system? My thinking has been that the
> device sending the notification knows the severity of the problem and
> - for example the REGULATOR_EVENT_REGULATION_OUT is only sent with
> such severe problems that consumers can try disabling the regulator,
> whereas the _WARN level notifications may not warrant such action. But
> again, I don't think we have a specification for this - so this is
> just my thinking - which may be off.

Do we actually have practical examples of systems sending warnings that
aren't followed in very short order by more severe errors, notified or
otherwise?

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

Powered by blists - more mailing lists