| Message ID | 20230410202917.247666-6-marijn.suijten@somainline.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | dts: qcom: Use labels with generic node names for ADC channels | expand |
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
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! 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
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"; }; }; };
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(-)