Greg Kroah-Hartman
598cf27219
Link: https://lore.kernel.org/r/20260217200002.683975158@linuxfoundation.org Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
39 lines
1.3 KiB
ReStructuredText
39 lines
1.3 KiB
ReStructuredText
==========================
|
|
Regulator API design notes
|
|
==========================
|
|
|
|
This document provides a brief, partially structured, overview of some
|
|
of the design considerations which impact the regulator API design.
|
|
|
|
Safety
|
|
------
|
|
|
|
- Errors in regulator configuration can have very serious consequences
|
|
for the system, potentially including lasting hardware damage.
|
|
- It is not possible to automatically determine the power configuration
|
|
of the system - software-equivalent variants of the same chip may
|
|
have different power requirements, and not all components with power
|
|
requirements are visible to software.
|
|
|
|
.. note::
|
|
|
|
The API should make no changes to the hardware state unless it has
|
|
specific knowledge that these changes are safe to perform on this
|
|
particular system.
|
|
|
|
Consumer use cases
|
|
------------------
|
|
|
|
- The overwhelming majority of devices in a system will have no
|
|
requirement to do any runtime configuration of their power beyond
|
|
being able to turn it on or off.
|
|
|
|
- Many of the power supplies in the system will be shared between many
|
|
different consumers.
|
|
|
|
.. note::
|
|
|
|
The consumer API should be structured so that these use cases are
|
|
very easy to handle and so that consumers will work with shared
|
|
supplies without any additional effort.
|