Messages in this thread |  | | Date | Thu, 27 Oct 2022 11:42:18 -0700 | From | Zev Weiss <> | Subject | Re: [PATCH 2/3] dt-bindings: regulator: Add regulator-output binding |
| |
On Thu, Sep 29, 2022 at 02:27:20PM PDT, Zev Weiss wrote: >On Thu, Sep 29, 2022 at 02:07:14PM PDT, Rob Herring wrote: >>On Sun, Sep 25, 2022 at 03:03:18PM -0700, Zev Weiss wrote: >>>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 >>> >>>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 >> >>I'm not too sure about this one as there could be various times when >>control is relinquished. It is userspace closing its access? >>driver unbind? module unload? Does a bootloader pay attention to this? >> >>Rob > >Thanks for the feedback, Rob -- I'll admit I was a bit unsure how to >approach that, and this may well not be the right answer. What I'm >really aiming for is an appropriate way to express that regulator >on/off state should only ever be changed by explicit (external, e.g. >userspace) request, never as any sort of default/automatic action. >The two obvious things to guard against there seem to be automatic >enablement during initialization and automatic disablement on de-init >(shutdown, unbind, etc.). The former I think can be avoided by simply >not setting regulator-boot-on, so I added this as a corresponding >property to avoid the latter. > >I'm definitely open to suggestions for a better approach though. >
Ping...
Would something like this be preferable as a more direct description of that?
regulator-manually-controlled: description: | The regulator should never be enabled or disabled automatically, only when explicitly requested by an external actor (e.g. userspace). type: boolean
That would leave the question of which property takes priority if both regulator-manually-controlled and regulator-boot-on are set -- should the binding document the answer to that? (I personally don't have a strong opinion on which it should be.)
Thanks, Zev
|  |