On Wed, Oct 11, 2023 at 12:38:19PM +0100, Mark Brown wrote: > On Wed, Oct 11, 2023 at 09:59:31AM +0200, Oleksij Rempel wrote: > > > Configuration through the device tree and kernel defaults is preferable. > > For instance, having a default kernel governor that doesn’t require user > > space configuration aligns with the project’s objectives. > > That's policy though... > > > > > > For the regulator itself we probably want a way to identify regulators > > > as being system critical so they start notifying. It would be tempting Can the "criticality" could be determined by the severity (ERROR vs WARNING)? > > > to just do that by default but that would likely cause some issues for > > > example with regulators for things like SD cards which are more likely > > > to get hardware problems that don't comprimise the entire system. We "comprimise the entire system" sounds (to my ears) exactly the difference between WARNING and ERROR notifications. > > > could do that with DT, either a property or some sort of runtime > > > consumer, but it might be better to have a control in sysfs that > > > userspace can turn on? OTOH the ability do something about this depends > > > on specific hardware design... > > > > > > I've copied in Sebastian since this sounds like the sort of thing that > > > power supplies might have some kind of handling for, or at least if we > > > need to add something we should make it so that the power supplies can > > > be joined up to it. I do see temperature and capacity alerts in the > > > sysfs ABI for power supplies, but nothing for voltage. > > > > Thank you for pointing towards the power supply framework. Given the hardware > > design of my project, I can envision mapping the following states and > > properties within this framework: > > There's also hw_failure_emergency_poweroff() which looks like exactly > what you're trying to trigger here. There is already a path from regulator notification handling to the hw_failure_emergency_poweroff() - although only when handling the IRQs fail and this failure is marked as fatal. > > Considering the above mapping, my initial step would be to create a simple > > regulator coupled (if regulator is still needed in this casr) with a Device > > Tree (DT) based power supply driver. This setup would align with the existing > > power supply framework, with a notable extension being the system-wide > > notification for emergency shutdown upon under-voltage detection. > > It sounds like this is actually a regulator regardless of if it also > appears via some other API. I wonder if it would make sense to add a 'protector' in regulator core. The 'protector' could register to listen the notifications from those regulators which have some 'regulator-fatal-notifications = <list of notifications>;' -property defined in device-tree. In my eyes the device-tree is correct place for this information because whether an "anomaly" in regulator output compromises the system is a property of hardware. Yours, -- Matti -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
Attachment:
signature.asc
Description: PGP signature
