v4:
- Add 9elements as vendor.
- Update dt binding.
Add devicetree support of the output-supply driver.
The supply names for this driver is provided through DT
regulator-names & regulator handle can be acquired.
Driver events can be received from sysfs.
Laxman Dewangan (1):
regulator: output-supply: Add devicetree support
Naresh Solanki (2):
dt-bindings: vendor-prefixes: add 9elements
dt-bindings: regulator: add bindings for output-supply
Patrick Rudolph (1):
regulator: output-supply: Add Notification support
.../regulator/9elements,output-supply.yaml | 63 ++++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
drivers/regulator/userspace-consumer.c | 97 ++++++++++++++++++-
3 files changed, 160 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/9elements,output-supply.yaml
base-commit: 9f09069cde34dcd86f5ecf3a3139fd752020812f
prerequisite-patch-id: 0000000000000000000000000000000000000000
--
2.35.3
Add a devicetree binding for the 9elements,output-supply driver.
Example is also provided.
Signed-off-by: Naresh Solanki <[email protected]>
---
.../regulator/9elements,output-supply.yaml | 63 +++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/9elements,output-supply.yaml
diff --git a/Documentation/devicetree/bindings/regulator/9elements,output-supply.yaml b/Documentation/devicetree/bindings/regulator/9elements,output-supply.yaml
new file mode 100644
index 000000000000..e4b67bc0794f
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/9elements,output-supply.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/userspace-consumer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Regulator output-supply driver
+
+maintainers:
+ - Patrick Rudolph <[email protected]>
+
+description: |
+ Regulator output-supply driver helps interact with regulator.
+ Provides regulator events & sysfs notify to capture regulator events
+ in realtime for userspace application.
+ This enables userspace application to monitor events in regulator(s) &
+ handle them appropriately.
+
+
+properties:
+ compatible:
+ enum:
+ - 9elements,output-supply
+
+ regulator-name:
+ description: Name of the consumer line
+
+ regulator-boot-on:
+ description: Enable regulator during boot
+
+ regulator-supplies:
+ description: Supply names for this regulator. This can be multiple strings
+
+patternProperties:
+ ".*-supply$":
+ description: |
+ Input supply phandle(s) for this node. There should be
+ <supply-name>-supply to pass regulators handle
+
+required:
+ - compatible
+ - regulator-supplies
+ - ".*-supply$"
+
+additionalProperties: false
+
+examples:
+ - |
+ p12v_b_consumer {
+ compatible = "9elements,output-supply";
+ regulator-name = "BCM1";
+ regulator-supplies = "vbus";
+ vbus-supply = <&p12v_b>;
+ };
+
+ ssb_rssd32 {
+ compatible = "9elements,output-supply";
+ regulator-name = "ssb_rssd32";
+ regulator-supplies = "sw0", "sw1";
+ sw0-supply = <&sw0_ssb_rssd32>;
+ sw1-supply = <&sw1_ssb_rssd32>;
+ };
+...
--
2.35.3
On Thu, Jul 07, 2022 at 10:18:24AM +0200, Naresh Solanki wrote:
> Add a devicetree binding for the 9elements,output-supply driver.
> Example is also provided.
It's fine this time but in general if you're sending a patch series you
should always ensure that at least the cover letter goes to all the
relevant maintainers so that they know what's going on with
dependencies.
On Thu, 7 Jul 2022 10:18:22 +0200, Naresh Solanki wrote:
> v4:
> - Add 9elements as vendor.
> - Update dt binding.
>
> Add devicetree support of the output-supply driver.
> The supply names for this driver is provided through DT
> regulator-names & regulator handle can be acquired.
> Driver events can be received from sysfs.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/4] dt-bindings: vendor-prefixes: add 9elements
commit: bd9b7998b4816b3d604253a774d83b6736474283
[2/4] dt-bindings: regulator: add bindings for output-supply
commit: df9c96b69a1d2629519a5d8a9dc4b39f775ebe2d
[3/4] regulator: output-supply: Add devicetree support
commit: 34e5700e1e64077ede50eb60d04e7604dc4f508a
[4/4] regulator: output-supply: Add Notification support
commit: 490a15324ce6d55b950fce0eb9e95c793fac0dff
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
On Mon, Jul 11, 2022 at 08:11:02PM +0100, Mark Brown wrote:
> On Thu, 7 Jul 2022 10:18:22 +0200, Naresh Solanki wrote:
> > v4:
> > - Add 9elements as vendor.
> > - Update dt binding.
> >
> > Add devicetree support of the output-supply driver.
> > The supply names for this driver is provided through DT
> > regulator-names & regulator handle can be acquired.
> > Driver events can be received from sysfs.
> >
> > [...]
>
> Applied to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
>
> Thanks!
>
> [1/4] dt-bindings: vendor-prefixes: add 9elements
> commit: bd9b7998b4816b3d604253a774d83b6736474283
> [2/4] dt-bindings: regulator: add bindings for output-supply
> commit: df9c96b69a1d2629519a5d8a9dc4b39f775ebe2d
> [3/4] regulator: output-supply: Add devicetree support
> commit: 34e5700e1e64077ede50eb60d04e7604dc4f508a
> [4/4] regulator: output-supply: Add Notification support
> commit: 490a15324ce6d55b950fce0eb9e95c793fac0dff
Please revert this. The vendor prefix is not even appropriate here and
the binding has lots of issues. The first being whether it should even
be in DT. It's not been reviewed as none of it has gone to the DT list
and the only thing I got was '[PATCH v4 1/4] dt-bindings:
vendor-prefixes: add 9elements'.
Rob
On Thu, Jul 14, 2022 at 8:14 AM Mark Brown <[email protected]> wrote:
>
> On Thu, Jul 14, 2022 at 08:10:41AM -0600, Rob Herring wrote:
> > On Thu, Jul 07, 2022 at 10:18:24AM +0200, Naresh Solanki wrote:
> > > Add a devicetree binding for the 9elements,output-supply driver.
>
> > > +properties:
> > > + compatible:
> > > + enum:
> > > + - 9elements,output-supply
>
> > Why does this have a vendor prefix when it appears to be a s/w
> > construct?
>
> It's a description of a power supply output from their system (system as
> a whole, not power provisioned within the system).
Well, that's a better commit message than the original, but I still
don't understand.
Rob
On Thu, Jul 07, 2022 at 10:18:24AM +0200, Naresh Solanki wrote:
> Add a devicetree binding for the 9elements,output-supply driver.
> Example is also provided.
>
> Signed-off-by: Naresh Solanki <[email protected]>
> ---
> .../regulator/9elements,output-supply.yaml | 63 +++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/9elements,output-supply.yaml
Now failing in linux-next. Please send an incremental patch to fix (and
test it yourself):
/builds/robherring/linux-dt/Documentation/devicetree/bindings/regulator/9elements,output-supply.yaml: required:2: '.*-supply$' does not match '^([a-zA-Z#][a-zA-Z0-9,+\\-._@]{0,63}|\\$nodename)$'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
./Documentation/devicetree/bindings/regulator/9elements,output-supply.yaml: $id: relative path/filename doesn't match actual path or filename
expected: http://devicetree.org/schemas/regulator/9elements,output-supply.yaml#
On Thu, Jul 07, 2022 at 10:18:24AM +0200, Naresh Solanki wrote:
> Add a devicetree binding for the 9elements,output-supply driver.
Bindings are for h/w, not drivers.
> Example is also provided.
>
> Signed-off-by: Naresh Solanki <[email protected]>
> ---
> .../regulator/9elements,output-supply.yaml | 63 +++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/9elements,output-supply.yaml
>
> diff --git a/Documentation/devicetree/bindings/regulator/9elements,output-supply.yaml b/Documentation/devicetree/bindings/regulator/9elements,output-supply.yaml
> new file mode 100644
> index 000000000000..e4b67bc0794f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/9elements,output-supply.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/userspace-consumer.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Regulator output-supply driver
> +
> +maintainers:
> + - Patrick Rudolph <[email protected]>
> +
> +description: |
> + Regulator output-supply driver helps interact with regulator.
> + Provides regulator events & sysfs notify to capture regulator events
> + in realtime for userspace application.
> + This enables userspace application to monitor events in regulator(s) &
> + handle them appropriately.
What does userspace have to do with hardware description?
> +
> +
> +properties:
> + compatible:
> + enum:
> + - 9elements,output-supply
Why does this have a vendor prefix when it appears to be a s/w
construct?
> +
> + regulator-name:
> + description: Name of the consumer line
> +
> + regulator-boot-on:
> + description: Enable regulator during boot
> +
> + regulator-supplies:
> + description: Supply names for this regulator. This can be multiple strings
What's the type for this?
The supply names are the prefix on -supply properties.
> +
> +patternProperties:
> + ".*-supply$":
> + description: |
> + Input supply phandle(s) for this node. There should be
> + <supply-name>-supply to pass regulators handle
> +
> +required:
> + - compatible
> + - regulator-supplies
> + - ".*-supply$"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + p12v_b_consumer {
> + compatible = "9elements,output-supply";
> + regulator-name = "BCM1";
> + regulator-supplies = "vbus";
> + vbus-supply = <&p12v_b>;
> + };
> +
> + ssb_rssd32 {
> + compatible = "9elements,output-supply";
> + regulator-name = "ssb_rssd32";
> + regulator-supplies = "sw0", "sw1";
> + sw0-supply = <&sw0_ssb_rssd32>;
> + sw1-supply = <&sw1_ssb_rssd32>;
> + };
> +...
> --
> 2.35.3
>
>
On Thu, Jul 14, 2022 at 08:10:41AM -0600, Rob Herring wrote:
> On Thu, Jul 07, 2022 at 10:18:24AM +0200, Naresh Solanki wrote:
> > Add a devicetree binding for the 9elements,output-supply driver.
> > +properties:
> > + compatible:
> > + enum:
> > + - 9elements,output-supply
> Why does this have a vendor prefix when it appears to be a s/w
> construct?
It's a description of a power supply output from their system (system as
a whole, not power provisioned within the system).
On Thu, Jul 14, 2022 at 08:23:39AM -0600, Rob Herring wrote:
> On Thu, Jul 14, 2022 at 8:14 AM Mark Brown <[email protected]> wrote:
> > It's a description of a power supply output from their system (system as
> > a whole, not power provisioned within the system).
> Well, that's a better commit message than the original, but I still
> don't understand.
Consider for example a BMC (IIRC that's what their specific product is),
a bench supply or some automated test equipment. Part of the function
for these systems is to provide power to other systems which would be
represented as a root or wall supply in the description of the system
that actually uses the supply if it were described using DT.
On Thu, Jul 14, 2022 at 8:43 AM Mark Brown <[email protected]> wrote:
>
> On Thu, Jul 14, 2022 at 08:23:39AM -0600, Rob Herring wrote:
> > On Thu, Jul 14, 2022 at 8:14 AM Mark Brown <[email protected]> wrote:
>
> > > It's a description of a power supply output from their system (system as
> > > a whole, not power provisioned within the system).
>
> > Well, that's a better commit message than the original, but I still
> > don't understand.
>
> Consider for example a BMC (IIRC that's what their specific product is),
> a bench supply or some automated test equipment. Part of the function
> for these systems is to provide power to other systems which would be
> represented as a root or wall supply in the description of the system
> that actually uses the supply if it were described using DT.
Didn't someone else have a similar use recently? Controlling some
supply external to the system. I can't seem to find it now.
In any case, it's not for you to describe, but Naresh, and in the
binding and commit messages. But first we need to overcome proper
usage of get_maintainers.pl. In response, to my first reply on v4, I
have a second v4 sent privately today (and still only the vendor
prefix). Sigh. AFAICT, for v1-v3, the only thing that made it to the
list was the cover letters. Bottom line is this series has multiple
problems and shouldn't have been applied yet.
Rob
On Thu, Jul 14, 2022 at 09:07:49AM -0600, Rob Herring wrote:
> On Thu, Jul 14, 2022 at 8:43 AM Mark Brown <[email protected]> wrote:
> > Consider for example a BMC (IIRC that's what their specific product is),
> > a bench supply or some automated test equipment. Part of the function
> > for these systems is to provide power to other systems which would be
> > represented as a root or wall supply in the description of the system
> > that actually uses the supply if it were described using DT.
> Didn't someone else have a similar use recently? Controlling some
> supply external to the system. I can't seem to find it now.
IIRC that was an earlier iteration of the same thing - it's been round
the houses a bit. extcon seemed like it might be a home since these are
external connections from the system but in the end people didn't think
it looked like a good fit.
> In any case, it's not for you to describe, but Naresh, and in the
> binding and commit messages. But first we need to overcome proper
> usage of get_maintainers.pl. In response, to my first reply on v4, I
> have a second v4 sent privately today (and still only the vendor
> prefix). Sigh. AFAICT, for v1-v3, the only thing that made it to the
> list was the cover letters. Bottom line is this series has multiple
> problems and shouldn't have been applied yet.
I can drop it but I do think it's reasonable to be adding a vendor
binding for this, we don't seem to have enough people engaged to scope
out a generic binding confidently and TBH I've got a feeling we might
want multiple application specific generic bindings when we do have one.
+Zev
On Thu, Jul 14, 2022 at 9:54 AM Mark Brown <[email protected]> wrote:
>
> On Thu, Jul 14, 2022 at 09:07:49AM -0600, Rob Herring wrote:
> > On Thu, Jul 14, 2022 at 8:43 AM Mark Brown <[email protected]> wrote:
>
> > > Consider for example a BMC (IIRC that's what their specific product is),
> > > a bench supply or some automated test equipment. Part of the function
> > > for these systems is to provide power to other systems which would be
> > > represented as a root or wall supply in the description of the system
> > > that actually uses the supply if it were described using DT.
>
> > Didn't someone else have a similar use recently? Controlling some
> > supply external to the system. I can't seem to find it now.
>
> IIRC that was an earlier iteration of the same thing - it's been round
> the houses a bit. extcon seemed like it might be a home since these are
> external connections from the system but in the end people didn't think
> it looked like a good fit.
Found it:
v1: https://lore.kernel.org/all/[email protected]/
v2: https://lore.kernel.org/all/[email protected]/
v2 was the using extcon version. v1 looks pretty similar to this one
though anything that's just a compatible plus supplies would.
But AFAICT these 2 submissions are completely independent.
> > In any case, it's not for you to describe, but Naresh, and in the
> > binding and commit messages. But first we need to overcome proper
> > usage of get_maintainers.pl. In response, to my first reply on v4, I
> > have a second v4 sent privately today (and still only the vendor
> > prefix). Sigh. AFAICT, for v1-v3, the only thing that made it to the
> > list was the cover letters. Bottom line is this series has multiple
> > problems and shouldn't have been applied yet.
>
> I can drop it but I do think it's reasonable to be adding a vendor
> binding for this, we don't seem to have enough people engaged to scope
> out a generic binding confidently and TBH I've got a feeling we might
> want multiple application specific generic bindings when we do have one.
I don't mind the vendor prefix. I mind the vendor prefix without any
description of the vendor's h/w.
Rob
On Thu, Jul 14, 2022 at 10:59:48AM -0600, Rob Herring wrote:
> On Thu, Jul 14, 2022 at 9:54 AM Mark Brown <[email protected]> wrote:
> > On Thu, Jul 14, 2022 at 09:07:49AM -0600, Rob Herring wrote:
> > > On Thu, Jul 14, 2022 at 8:43 AM Mark Brown <[email protected]> wrote:
> > IIRC that was an earlier iteration of the same thing - it's been round
> > the houses a bit. extcon seemed like it might be a home since these are
> > external connections from the system but in the end people didn't think
> > it looked like a good fit.
> Found it:
> v1: https://lore.kernel.org/all/[email protected]/
> v2: https://lore.kernel.org/all/[email protected]/
> v2 was the using extcon version. v1 looks pretty similar to this one
> though anything that's just a compatible plus supplies would.
> But AFAICT these 2 submissions are completely independent.
Yes, I think so - I'd misremembered as being the same thing due to the
serialisation.
On Thu, Jul 14, 2022 at 08:17:12AM -0600, Rob Herring wrote:
> Please revert this. The vendor prefix is not even appropriate here and
> the binding has lots of issues. The first being whether it should even
> be in DT. It's not been reviewed as none of it has gone to the DT list
> and the only thing I got was '[PATCH v4 1/4] dt-bindings:
> vendor-prefixes: add 9elements'.
As discussed on the other subthread while some of this might not be an
actual problem others are causing serious concern for Rob so I've
dropped this series, it was the top commit so I just reverted the merge.
Sorry about the hassle here, hopefully the issues Rob has raised can be
addressed.
On Thu, Jul 14, 2022 at 09:59:48AM PDT, Rob Herring wrote:
>+Zev
>
>On Thu, Jul 14, 2022 at 9:54 AM Mark Brown <[email protected]> wrote:
>>
>> On Thu, Jul 14, 2022 at 09:07:49AM -0600, Rob Herring wrote:
>> > On Thu, Jul 14, 2022 at 8:43 AM Mark Brown <[email protected]> wrote:
>>
>> > > Consider for example a BMC (IIRC that's what their specific product is),
>> > > a bench supply or some automated test equipment. Part of the function
>> > > for these systems is to provide power to other systems which would be
>> > > represented as a root or wall supply in the description of the system
>> > > that actually uses the supply if it were described using DT.
>>
>> > Didn't someone else have a similar use recently? Controlling some
>> > supply external to the system. I can't seem to find it now.
>>
>> IIRC that was an earlier iteration of the same thing - it's been round
>> the houses a bit. extcon seemed like it might be a home since these are
>> external connections from the system but in the end people didn't think
>> it looked like a good fit.
>
>Found it:
>
>v1: https://lore.kernel.org/all/[email protected]/
>v2: https://lore.kernel.org/all/[email protected]/
>
>v2 was the using extcon version. v1 looks pretty similar to this one
>though anything that's just a compatible plus supplies would.
>
>But AFAICT these 2 submissions are completely independent.
>
Thanks for looping me in here Rob, I hadn't been aware of this series.
Naresh, I'd appreciate it if you could CC me on any subsequent
iterations; as linked above I've made some sporadic attempts at getting
support for this functionality merged, and am certainly interested in
any other efforts on that front.
A question for Mark though -- in one of my earliest stabs at this I
floated the idea of using reg-userspace-consumer for it, but was told in
no uncertain terms that that driver was for testing only and should
under no circumstances ever be instantiated in a production system. Has
the thinking on its usage changed in the last year or so such that this
approach was deemed okay?
Thanks,
Zev
On Thu, Jul 21, 2022 at 01:33:20AM -0700, Zev Weiss wrote:
> A question for Mark though -- in one of my earliest stabs at this I floated
> the idea of using reg-userspace-consumer for it, but was told in no
> uncertain terms that that driver was for testing only and should under no
> circumstances ever be instantiated in a production system. Has the thinking
> on its usage changed in the last year or so such that this approach was
> deemed okay?
I was talked around after some discussion of the use case. It's still
not a great API but for at least some of these users it'll do. It's
important that it not appear directly in bindings though.