As discussed in [1] it is more convenient to use a generic `channel`
node name for ADC channels while storing a friendly - board-specific
instead of PMIC-specific - name in the label, if/when desired to
overwrite the channel description already contained (but previously
unused) in the driver [2].
The same `channel` node name pattern has also been set in
iio/adc/adc.yaml, but this generic binding is not inherited as base for
qcom,spmi-vadc bindings due to not having any other generic elements in
common, besides the node name rule and reg property.
Replace the .* name pattern with the `channel` literal, but leave the
label property optional for bindings to choose to fall back a channel
label hardcoded in the driver [2] instead.
[1]: https://lore.kernel.org/linux-arm-msm/20221106193018.270106-1-marijn.suijten@somainline.org/T/#u
[2]: https://lore.kernel.org/linux-arm-msm/20230116220909.196926-4-marijn.suijten@somainline.org/
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
---
.../bindings/iio/adc/qcom,spmi-vadc.yaml | 26 ++++++++++---------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
index bd6e0d6f6e0c..f30114424b92 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
@@ -54,7 +54,7 @@ required:
- '#io-channel-cells'
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
type: object
additionalProperties: false
description: |
@@ -148,7 +148,7 @@ allOf:
then:
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
properties:
qcom,decimation:
enum: [ 512, 1024, 2048, 4096 ]
@@ -171,7 +171,7 @@ allOf:
then:
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
properties:
qcom,decimation:
enum: [ 256, 512, 1024 ]
@@ -194,7 +194,7 @@ allOf:
then:
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
properties:
qcom,decimation:
enum: [ 250, 420, 840 ]
@@ -217,7 +217,7 @@ allOf:
then:
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
properties:
qcom,decimation:
enum: [ 85, 340, 1360 ]
@@ -249,7 +249,7 @@ examples:
#io-channel-cells = <1>;
/* Channel node */
- adc-chan@39 {
+ channel@39 {
reg = <0x39>;
qcom,decimation = <512>;
qcom,ratiometric;
@@ -258,19 +258,19 @@ examples:
qcom,pre-scaling = <1 3>;
};
- adc-chan@9 {
+ channel@9 {
reg = <0x9>;
};
- adc-chan@a {
+ channel@a {
reg = <0xa>;
};
- adc-chan@e {
+ channel@e {
reg = <0xe>;
};
- adc-chan@f {
+ channel@f {
reg = <0xf>;
};
};
@@ -292,16 +292,18 @@ examples:
#io-channel-cells = <1>;
/* Other properties are omitted */
- xo-therm@44 {
+ channel@44 {
reg = <PMK8350_ADC7_AMUX_THM1_100K_PU>;
qcom,ratiometric;
qcom,hw-settle-time = <200>;
+ label = "xo_therm";
};
- conn-therm@47 {
+ channel@47 {
reg = <PM8350_ADC7_AMUX_THM4_100K_PU(1)>;
qcom,ratiometric;
qcom,hw-settle-time = <200>;
+ label = "conn_therm";
};
};
};
--
2.40.0On Mon, 10 Apr 2023 22:29:17 +0200
Marijn Suijten <marijn.suijten@somainline.org> wrote:
> As discussed in [1] it is more convenient to use a generic `channel`
> node name for ADC channels while storing a friendly - board-specific
> instead of PMIC-specific - name in the label, if/when desired to
> overwrite the channel description already contained (but previously
> unused) in the driver [2].
>
> The same `channel` node name pattern has also been set in
> iio/adc/adc.yaml, but this generic binding is not inherited as base for
> qcom,spmi-vadc bindings due to not having any other generic elements in
> common, besides the node name rule and reg property.
>
> Replace the .* name pattern with the `channel` literal, but leave the
> label property optional for bindings to choose to fall back a channel
> label hardcoded in the driver [2] instead.
>
> [1]: https://lore.kernel.org/linux-arm-msm/20221106193018.270106-1-marijn.suijten@somainline.org/T/#u
> [2]: https://lore.kernel.org/linux-arm-msm/20230116220909.196926-4-marijn.suijten@somainline.org/
>
> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
There are various ways we could pick up this patch set...
a) Binding changes via individual subsystem trees,
b) All in on go.
I think it's late to guarantee to land the changes from (a) in the coming merge window
so if someone else is willing to do (b) then
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Otherwise we can do (a) early in next cycle. Feel free to poke me if we are doing (b)
and I seem to have forgotten to pick up this patch!
Jonathan
> ---
> .../bindings/iio/adc/qcom,spmi-vadc.yaml | 26 ++++++++++---------
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
> index bd6e0d6f6e0c..f30114424b92 100644
> --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
> @@ -54,7 +54,7 @@ required:
> - '#io-channel-cells'
>
> patternProperties:
> - "^.*@[0-9a-f]+$":
> + "^channel@[0-9a-f]+$":
> type: object
> additionalProperties: false
> description: |
> @@ -148,7 +148,7 @@ allOf:
>
> then:
> patternProperties:
> - "^.*@[0-9a-f]+$":
> + "^channel@[0-9a-f]+$":
> properties:
> qcom,decimation:
> enum: [ 512, 1024, 2048, 4096 ]
> @@ -171,7 +171,7 @@ allOf:
>
> then:
> patternProperties:
> - "^.*@[0-9a-f]+$":
> + "^channel@[0-9a-f]+$":
> properties:
> qcom,decimation:
> enum: [ 256, 512, 1024 ]
> @@ -194,7 +194,7 @@ allOf:
>
> then:
> patternProperties:
> - "^.*@[0-9a-f]+$":
> + "^channel@[0-9a-f]+$":
> properties:
> qcom,decimation:
> enum: [ 250, 420, 840 ]
> @@ -217,7 +217,7 @@ allOf:
>
> then:
> patternProperties:
> - "^.*@[0-9a-f]+$":
> + "^channel@[0-9a-f]+$":
> properties:
> qcom,decimation:
> enum: [ 85, 340, 1360 ]
> @@ -249,7 +249,7 @@ examples:
> #io-channel-cells = <1>;
>
> /* Channel node */
> - adc-chan@39 {
> + channel@39 {
> reg = <0x39>;
> qcom,decimation = <512>;
> qcom,ratiometric;
> @@ -258,19 +258,19 @@ examples:
> qcom,pre-scaling = <1 3>;
> };
>
> - adc-chan@9 {
> + channel@9 {
> reg = <0x9>;
> };
>
> - adc-chan@a {
> + channel@a {
> reg = <0xa>;
> };
>
> - adc-chan@e {
> + channel@e {
> reg = <0xe>;
> };
>
> - adc-chan@f {
> + channel@f {
> reg = <0xf>;
> };
> };
> @@ -292,16 +292,18 @@ examples:
> #io-channel-cells = <1>;
>
> /* Other properties are omitted */
> - xo-therm@44 {
> + channel@44 {
> reg = <PMK8350_ADC7_AMUX_THM1_100K_PU>;
> qcom,ratiometric;
> qcom,hw-settle-time = <200>;
> + label = "xo_therm";
> };
>
> - conn-therm@47 {
> + channel@47 {
> reg = <PM8350_ADC7_AMUX_THM4_100K_PU(1)>;
> qcom,ratiometric;
> qcom,hw-settle-time = <200>;
> + label = "conn_therm";
> };
> };
> };
On 2023-04-12 21:27:56, Jonathan Cameron wrote: > On Mon, 10 Apr 2023 22:29:17 +0200 > Marijn Suijten <marijn.suijten@somainline.org> wrote: > > > As discussed in [1] it is more convenient to use a generic `channel` > > node name for ADC channels while storing a friendly - board-specific > > instead of PMIC-specific - name in the label, if/when desired to > > overwrite the channel description already contained (but previously > > unused) in the driver [2]. > > > > The same `channel` node name pattern has also been set in > > iio/adc/adc.yaml, but this generic binding is not inherited as base for > > qcom,spmi-vadc bindings due to not having any other generic elements in > > common, besides the node name rule and reg property. > > > > Replace the .* name pattern with the `channel` literal, but leave the > > label property optional for bindings to choose to fall back a channel > > label hardcoded in the driver [2] instead. > > > > [1]: https://lore.kernel.org/linux-arm-msm/20221106193018.270106-1-marijn.suijten@somainline.org/T/#u > > [2]: https://lore.kernel.org/linux-arm-msm/20230116220909.196926-4-marijn.suijten@somainline.org/ > > > > Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> > > There are various ways we could pick up this patch set... > a) Binding changes via individual subsystem trees, > b) All in on go. > > I think it's late to guarantee to land the changes from (a) in the coming merge window > so if someone else is willing to do (b) then > > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > Otherwise we can do (a) early in next cycle. Feel free to poke me if we are doing (b) > and I seem to have forgotten to pick up this patch! Thanks! I hope we don't get many conflicts (+ new bindings adhering to the old(er) formats) otherwise I'll resend if we do (a). Around what time would be good, rc2? [..] - Marijn
On Wed, 12 Apr 2023 22:31:46 +0200 Marijn Suijten <marijn.suijten@somainline.org> wrote: > On 2023-04-12 21:27:56, Jonathan Cameron wrote: > > On Mon, 10 Apr 2023 22:29:17 +0200 > > Marijn Suijten <marijn.suijten@somainline.org> wrote: > > > > > As discussed in [1] it is more convenient to use a generic `channel` > > > node name for ADC channels while storing a friendly - board-specific > > > instead of PMIC-specific - name in the label, if/when desired to > > > overwrite the channel description already contained (but previously > > > unused) in the driver [2]. > > > > > > The same `channel` node name pattern has also been set in > > > iio/adc/adc.yaml, but this generic binding is not inherited as base for > > > qcom,spmi-vadc bindings due to not having any other generic elements in > > > common, besides the node name rule and reg property. > > > > > > Replace the .* name pattern with the `channel` literal, but leave the > > > label property optional for bindings to choose to fall back a channel > > > label hardcoded in the driver [2] instead. > > > > > > [1]: https://lore.kernel.org/linux-arm-msm/20221106193018.270106-1-marijn.suijten@somainline.org/T/#u > > > [2]: https://lore.kernel.org/linux-arm-msm/20230116220909.196926-4-marijn.suijten@somainline.org/ > > > > > > Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> > > > > There are various ways we could pick up this patch set... > > a) Binding changes via individual subsystem trees, > > b) All in on go. > > > > I think it's late to guarantee to land the changes from (a) in the coming merge window > > so if someone else is willing to do (b) then > > > > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > Otherwise we can do (a) early in next cycle. Feel free to poke me if we are doing (b) > > and I seem to have forgotten to pick up this patch! > > Thanks! I hope we don't get many conflicts (+ new bindings adhering to > the old(er) formats) otherwise I'll resend if we do (a). Around what > time would be good, rc2? Sure. If rebase is needed send a v5 with that done. If not, a simple reminder reply to this thread will probably work. Thanks, Jonathan > > [..] > > - Marijn
On Sat, 15 Apr 2023 17:49:43 +0100 Jonathan Cameron <jic23@kernel.org> wrote: > On Wed, 12 Apr 2023 22:31:46 +0200 > Marijn Suijten <marijn.suijten@somainline.org> wrote: > > > On 2023-04-12 21:27:56, Jonathan Cameron wrote: > > > On Mon, 10 Apr 2023 22:29:17 +0200 > > > Marijn Suijten <marijn.suijten@somainline.org> wrote: > > > > > > > As discussed in [1] it is more convenient to use a generic `channel` > > > > node name for ADC channels while storing a friendly - board-specific > > > > instead of PMIC-specific - name in the label, if/when desired to > > > > overwrite the channel description already contained (but previously > > > > unused) in the driver [2]. > > > > > > > > The same `channel` node name pattern has also been set in > > > > iio/adc/adc.yaml, but this generic binding is not inherited as base for > > > > qcom,spmi-vadc bindings due to not having any other generic elements in > > > > common, besides the node name rule and reg property. > > > > > > > > Replace the .* name pattern with the `channel` literal, but leave the > > > > label property optional for bindings to choose to fall back a channel > > > > label hardcoded in the driver [2] instead. > > > > > > > > [1]: https://lore.kernel.org/linux-arm-msm/20221106193018.270106-1-marijn.suijten@somainline.org/T/#u > > > > [2]: https://lore.kernel.org/linux-arm-msm/20230116220909.196926-4-marijn.suijten@somainline.org/ > > > > > > > > Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> > > > > > > There are various ways we could pick up this patch set... > > > a) Binding changes via individual subsystem trees, > > > b) All in on go. > > > > > > I think it's late to guarantee to land the changes from (a) in the coming merge window > > > so if someone else is willing to do (b) then > > > > > > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > > Otherwise we can do (a) early in next cycle. Feel free to poke me if we are doing (b) > > > and I seem to have forgotten to pick up this patch! > > > > Thanks! I hope we don't get many conflicts (+ new bindings adhering to > > the old(er) formats) otherwise I'll resend if we do (a). Around what > > time would be good, rc2? > > Sure. If rebase is needed send a v5 with that done. If not, a simple > reminder reply to this thread will probably work. I've started queuing stuff for the next cycle as the relevant pull requests are for the IIO tree for this cycle were picked up a few days ago. Hence, applied to the togreg branch of iio.git and pushed out as testing for 0-day to take a quick look at it. Thanks, Jonathan > > Thanks, > > Jonathan > > > > > [..] > > > > - Marijn >
On 2023-05-01 17:18:38, Jonathan Cameron wrote:
<snip>
> > > > Otherwise we can do (a) early in next cycle. Feel free to poke me if we are doing (b)
> > > > and I seem to have forgotten to pick up this patch!
> > >
> > > Thanks! I hope we don't get many conflicts (+ new bindings adhering to
> > > the old(er) formats) otherwise I'll resend if we do (a). Around what
> > > time would be good, rc2?
> >
> > Sure. If rebase is needed send a v5 with that done. If not, a simple
> > reminder reply to this thread will probably work.
>
> I've started queuing stuff for the next cycle as the relevant pull requests
> are for the IIO tree for this cycle were picked up a few days ago.
>
> Hence, applied to the togreg branch of iio.git and pushed out as testing for 0-day
> to take a quick look at it.
Thanks, running with:
make VALIDATE_DT=1 ARCH=arm64 dt_binding_checka dtbs_check \
DT_SCHEMA_FILES="Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml"
And similar for ARCH=arm on -next-20230428 shows that there is no new
use of the old (arbitrary) node name format, so no v5 should be
necessary (unless those patches also land at the same time...).
Such a resend would only affect patch 1/5 and 3/5 though, which rewrite
the actual DTS node names.
- Marijn
On 10/04/2023 22:29, Marijn Suijten wrote: > As discussed in [1] it is more convenient to use a generic `channel` > node name for ADC channels while storing a friendly - board-specific > instead of PMIC-specific - name in the label, if/when desired to > overwrite the channel description already contained (but previously > unused) in the driver [2]. > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.