---

yaml
---
r: 165407
b: refs/heads/master
c: 63209a7
h: refs/heads/master
i:
  165405: 3165d4b
  165403: 6245110
  165399: 33d931e
  165391: 7f8a281
  165375: f5d0b40
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 55c1d7c60d9b269551cd7cc31e6be8323e1d94ec
+refs/heads/master: 63209a71e8e7727f52208d17bb7180cd392edcfb

trunk/Documentation/power/regulator/design.txt

@@ -0,0 +1,33 @@
+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 confugration
+   of the system - software-equivalent variants of the same chip may
+   have different power requirments, and not all components with power
+   requirements are visible to software.
+
+  => The API should make no changes to the hardware state unless it has
+     specific knowledge that these changes are safe to do 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.
+
+  => 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.