to 6. huhtik. 2023 klo 16.43 Mark Brown (broonie@xxxxxxxxxx) kirjoitti:
>
> On Thu, Apr 06, 2023 at 11:00:02AM +0300, Matti Vaittinen wrote:
> > ke 5. huhtik. 2023 klo 18.19 Mark Brown (broonie@xxxxxxxxxx) kirjoitti:
> > > On Wed, Apr 05, 2023 at 07:18:32AM -0700, Guenter Roeck wrote:
> > > 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.
I have no concrete idea, just a vague uneasy feeling knowing that
devices tend to interact with each other. I guess it is more about the
amount of uncertainty caused by my lack of knowledge regarding what
could be done by these handlers. So, as I already said - if no one
else is bothered by this then I definitely don't want to block the
series. Still, if the error handling should be kept internal to PMBus
- then we should probably either say that consumer drivers must not
(forcibly) turn off the supply when receiving these notifications - or
not send these notifications from PMBus and allow PMBus to decide
error handling internally. (Again, I don't know if any in-tree
consumer drivers do turn off the supply regulator in error handlers -
but I don't think it is actually forbidden). Or am I just making a
problem that does not exist?
> > 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.
I would do at least two classes.
1) critical class - it is Ok for the consumer to forcibly shut down
the regulator, or maybe the whole system.
2) warning class - it is not Ok to forcibly shut down the regulator.
OTOH, after writing this down - if this was the division, then it
could be clearer to implement the shutdown at critical errors in the
regulator driver (or core) and just send a specific notification to
consumers telling this was done.
> > 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?
No. I don't. I will send one more question about the real-world use of
BD9576 'warning' level IRQs - but I am highly sceptical I will receive
any real information.
Thanks for the education and time Mark & Guenter. It's a bit hard for
me to let go of the thought that we would benefit from the handling of
different severity level errors - but maybe this was just my illusion
after all.
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));
