diff mbox series

[2/3] dt-bindings: regulator: Add regulator-output binding

Message ID 20220925220319.12572-3-zev@bewilderbeest.net
State New
Headers show
Series [1/3] regulator: devres: Add devm_regulator_bulk_get_exclusive() | expand

Commit Message

Zev Weiss Sept. 25, 2022, 10:03 p.m. UTC
This describes a power output supplied by a regulator, such as a
power outlet on a power distribution unit (PDU).

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
---
 .../bindings/regulator/regulator-output.yaml  | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/regulator-output.yaml

Comments

Zev Weiss Oct. 31, 2022, 6:50 p.m. UTC | #1
On Mon, Oct 31, 2022 at 08:45:34AM PDT, Mark Brown wrote:
>On Fri, Oct 28, 2022 at 12:44:50PM -0700, Zev Weiss wrote:
>> On Fri, Oct 28, 2022 at 08:51:54AM PDT, Mark Brown wrote:
>
>> > We don't turn things off on reboot?  We don't do anything in particular
>> > on reboot...
>
>> Okay, perhaps not on reboot specifically, but the userspace-consumer driver
>> has a regulator_bulk_disable() in its .remove function, so it would be
>> triggered at least by a module unload (which is sort of why I ended up with
>> the "when software relinquishes control" wording in the patch).  If we're
>> going to continue with the plan of using that driver for this functionality
>> (which seems overall quite reasonable to me), we need a way to express that
>> that must not happen on this hardware.
>
>Ah, that would be the test driver not intended to be used in production
>then...  That shouldn't be a blocker for the DT binding, and if there's
>a different compatible string for this application then we can either
>make the userspace consumer do something different based on that
>compatible string or have a new driver which does something more
>sensible and perhaps has a better userspace ABI.  Either way so long as
>we can tell the thing being described is a BMC output from the DT
>binding I think we can leave it up to the OS to do something constructive
>with that rather than trying to control the specific behaviour in the
>binding.

Ah, alright -- that seems like a nice (obvious in retrospect, of course) 
solution that should work well I think.  I'll post a v2 with that 
approach soon.


Thanks,
Zev
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/regulator/regulator-output.yaml b/Documentation/devicetree/bindings/regulator/regulator-output.yaml
new file mode 100644
index 000000000000..40953ec48e9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator-output.yaml
@@ -0,0 +1,47 @@ 
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/regulator/regulator-output.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Regulator output connector
+
+maintainers:
+  - Zev Weiss <zev@bewilderbeest.net>
+
+description: |
+  This describes a power output connector supplied by a regulator,
+  such as a power outlet on a power distribution unit (PDU).  The
+  connector may be standalone or merely one channel or set of pins
+  within a ganged physical connector carrying multiple independent
+  power outputs.
+
+properties:
+  compatible:
+    const: regulator-output
+
+  vout-supply:
+    description:
+      Phandle of the regulator supplying the output.
+
+  regulator-leave-on:
+    description: |
+      If the regulator is enabled when software relinquishes control
+      of it (such as when shutting down) it should be left enabled
+      instead of being turned off.
+    type: boolean
+
+required:
+  - compatible
+  - vout-supply
+
+additionalProperties: false
+
+examples:
+  - |
+      output {
+          compatible = "regulator-output";
+          vout-supply = <&output_reg>;
+          regulator-leave-on;
+      };