linux-kernel - Re: [PATCH v2 2/3] hwmon: (pmbus/core): Add regulator event support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANhJrGO3X7pSsMBg6Gtf-q3=_JiCX4Qs=pGudL=etooM2F676g@mail.gmail.com>
Date:   Thu, 6 Apr 2023 11:00:02 +0300
From:   Matti Vaittinen <mazziesaccount@...il.com>
To:     Mark Brown <broonie@...nel.org>
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

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.

> > if it observes a problem with the supplies it regulates, but based on your feedback
> > I am not sure anymore what those notifications are supposed to be used for,
> > and if such notifications are appropriate. That means I'll have to read up on all
> > this, and I don't have the time to do that in the near future given that I am buried
> > in pending reviews and the work I am actually getting paid for.
>
> 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.

As I said, this is my understanding only - I am not in a position
where I can tell people how to use these notifications. Still,
assuming PMBUS has its own handling for these errors (separately from
the regulator events), and assuming PMBUS does not want regulator
consumers to interfere with this handling - then I might avoid at
least sending the ERROR level notifications to regulator consumers.

> 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
b) Situations where different notification senders send similar
severity-level notifications for faults expecting different types of
handling.

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.

Yours,
    -- Matti

-- 

Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~

Discuss - Estimate - Plan - Report and finally accomplish this:
void do_work(int time) __attribute__ ((const));