Messages in this thread | | | Date | Tue, 23 May 2023 12:46:39 +0300 | From | Matti Vaittinen <> | Subject | Re: [PATCH RFC v3 1/5] regulator: move monitor handling into own function |
| |
Hi Benjamin,
Thanks for working on this. :)
On 5/21/23 14:39, Benjamin Bara wrote: > From: Benjamin Bara <benjamin.bara@skidata.com> > > Similar to the existing implementation, the new function does not handle > EOPNOTSUPP as an error. The initial monitoring state is set to the > regulator state.
As far as I see, this changes the existing logic. Previously the monitoring was unconditionally enabled for all regulators, now it gets only enabled for regulators which are marked as enabled.
Furthermore, if I am not reading this wrong, the code tries to disable all protections if regulator is not enabled at startup(?)
I am not saying this is wrong. I am just saying that things will change here and likely to break something.
There are PMICs like ROHM BD9576, where the protection can not be disabled.
For example, the bd9576_set_uvp() has: if (severity == REGULATOR_SEVERITY_PROT) { if (!enable || lim_uV) return -EINVAL; return 0; }
I am unsure if we might also have cases where some regulator could really be enabled w/o core knowing it. There can also be a problem if we have hardware where monitoring is common for all regulators, eg either globally enabled / disabled.
Yours, -- Matti
-- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
| |