In some cases, it is required to provide the state to which the mux
controller has be set to, from the consumer device tree node. Document the
property mux-states that can be used for adding this support.
Signed-off-by: Aswath Govindraju <[email protected]>
---
.../devicetree/bindings/mux/gpio-mux.yaml | 11 ++++++--
.../devicetree/bindings/mux/mux-consumer.yaml | 14 ++++++++++
.../bindings/mux/mux-controller.yaml | 26 ++++++++++++++++++-
3 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.yaml b/Documentation/devicetree/bindings/mux/gpio-mux.yaml
index 0a7c8d64981a..ee4de9fbaf4d 100644
--- a/Documentation/devicetree/bindings/mux/gpio-mux.yaml
+++ b/Documentation/devicetree/bindings/mux/gpio-mux.yaml
@@ -26,7 +26,10 @@ properties:
List of gpios used to control the multiplexer, least significant bit first.
'#mux-control-cells':
- const: 0
+ enum: [ 0, 1 ]
+
+ '#mux-state-cells':
+ enum: [ 1, 2 ]
idle-state:
default: -1
@@ -34,7 +37,11 @@ properties:
required:
- compatible
- mux-gpios
- - "#mux-control-cells"
+anyOf:
+ - required:
+ - "#mux-control-cells"
+ - required:
+ - "#mux-state-cells"
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
index 7af93298ab5c..64f353714227 100644
--- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
+++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
@@ -25,6 +25,11 @@ description: |
strings to label each of the mux controllers listed in the "mux-controls"
property.
+ If it is required to provide the state that the mux controller needs to
+ be set to, the property "mux-states" must be used. An optional property
+ "mux-state-names" can be used to provide a list of strings, to label
+ each of the mux controllers listed in the "mux-states" property.
+
mux-ctrl-specifier typically encodes the chip-relative mux controller number.
If the mux controller chip only provides a single mux controller, the
mux-ctrl-specifier can typically be left out.
@@ -35,12 +40,21 @@ properties:
mux-controls:
$ref: /schemas/types.yaml#/definitions/phandle-array
+ mux-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+
mux-control-names:
description:
Devices that use more than a single mux controller can use the
"mux-control-names" property to map the name of the requested mux
controller to an index into the list given by the "mux-controls" property.
+ mux-state-names:
+ description:
+ Devices that use more than a single mux controller can use the
+ "mux-state-names" property to map the name of the requested mux
+ controller to an index into the list given by the "mux-states" property.
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/mux/mux-controller.yaml b/Documentation/devicetree/bindings/mux/mux-controller.yaml
index 736a84c3b6a5..b29dbf521f01 100644
--- a/Documentation/devicetree/bindings/mux/mux-controller.yaml
+++ b/Documentation/devicetree/bindings/mux/mux-controller.yaml
@@ -25,7 +25,9 @@ description: |
--------------------
Mux controller nodes must specify the number of cells used for the
- specifier using the '#mux-control-cells' property.
+ specifier using the '#mux-control-cells' or 'mux-state-cells'
+ property. Value of '#mux-state-cells' will always be one greater then
+ the value of '#mux-control-cells'.
Optionally, mux controller nodes can also specify the state the mux should
have when it is idle. The idle-state property is used for this. If the
@@ -67,6 +69,8 @@ select:
pattern: '^mux-controller'
- required:
- '#mux-control-cells'
+ - required:
+ - '#mux-state-cells'
properties:
$nodename:
@@ -75,6 +79,9 @@ properties:
'#mux-control-cells':
enum: [ 0, 1 ]
+ '#mux-state-cells':
+ enum: [ 1, 2 ]
+
idle-state:
$ref: /schemas/types.yaml#/definitions/int32
minimum: -2
@@ -179,4 +186,21 @@ examples:
};
};
};
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ mux1: mux-controller {
+ compatible = "gpio-mux";
+ #mux-state-cells = <1>;
+ mux-gpios = <&exp_som 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ transceiver4: can-phy4 {
+ compatible = "ti,tcan1042";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ standby-gpios = <&exp_som 7 GPIO_ACTIVE_HIGH>;
+ mux-states = <&mux1 1>;
+ };
...
--
2.17.1
Hi Aswath!
Some language nits. But other than that it looks good to me!
On 2021-11-30 13:18, Aswath Govindraju wrote:
> In some cases, it is required to provide the state to which the mux
> controller has be set to, from the consumer device tree node. Document the
s/has be/has to be/
> property mux-states that can be used for adding this support.
>
> Signed-off-by: Aswath Govindraju <[email protected]>
> ---
> .../devicetree/bindings/mux/gpio-mux.yaml | 11 ++++++--
> .../devicetree/bindings/mux/mux-consumer.yaml | 14 ++++++++++
> .../bindings/mux/mux-controller.yaml | 26 ++++++++++++++++++-
> 3 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.yaml b/Documentation/devicetree/bindings/mux/gpio-mux.yaml
> index 0a7c8d64981a..ee4de9fbaf4d 100644
> --- a/Documentation/devicetree/bindings/mux/gpio-mux.yaml
> +++ b/Documentation/devicetree/bindings/mux/gpio-mux.yaml
> @@ -26,7 +26,10 @@ properties:
> List of gpios used to control the multiplexer, least significant bit first.
>
> '#mux-control-cells':
> - const: 0
> + enum: [ 0, 1 ]
> +
> + '#mux-state-cells':
> + enum: [ 1, 2 ]
>
> idle-state:
> default: -1
> @@ -34,7 +37,11 @@ properties:
> required:
> - compatible
> - mux-gpios
> - - "#mux-control-cells"
> +anyOf:
> + - required:
> + - "#mux-control-cells"
> + - required:
> + - "#mux-state-cells"
>
> additionalProperties: false
>
> diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> index 7af93298ab5c..64f353714227 100644
> --- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> @@ -25,6 +25,11 @@ description: |
> strings to label each of the mux controllers listed in the "mux-controls"
> property.
>
> + If it is required to provide the state that the mux controller needs to
> + be set to, the property "mux-states" must be used. An optional property
> + "mux-state-names" can be used to provide a list of strings, to label
> + each of the mux controllers listed in the "mux-states" property.
s/mux controllers/multiplexer states/
> +
> mux-ctrl-specifier typically encodes the chip-relative mux controller number.
> If the mux controller chip only provides a single mux controller, the
> mux-ctrl-specifier can typically be left out.
> @@ -35,12 +40,21 @@ properties:
> mux-controls:
> $ref: /schemas/types.yaml#/definitions/phandle-array
>
> + mux-states:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> mux-control-names:
> description:
> Devices that use more than a single mux controller can use the
> "mux-control-names" property to map the name of the requested mux
> controller to an index into the list given by the "mux-controls" property.
>
> + mux-state-names:
> + description:
> + Devices that use more than a single mux controller can use the
s/mux controller/multiplexer state/
> + "mux-state-names" property to map the name of the requested mux
> + controller to an index into the list given by the "mux-states" property.
And again, over the line break.
> +
> additionalProperties: true
>
> ...
> diff --git a/Documentation/devicetree/bindings/mux/mux-controller.yaml b/Documentation/devicetree/bindings/mux/mux-controller.yaml
> index 736a84c3b6a5..b29dbf521f01 100644
> --- a/Documentation/devicetree/bindings/mux/mux-controller.yaml
> +++ b/Documentation/devicetree/bindings/mux/mux-controller.yaml
> @@ -25,7 +25,9 @@ description: |
> --------------------
>
> Mux controller nodes must specify the number of cells used for the
> - specifier using the '#mux-control-cells' property.
> + specifier using the '#mux-control-cells' or 'mux-state-cells'
'#mux-state-cells' (missing #)
> + property. Value of '#mux-state-cells' will always be one greater then
s/Value/The value/
s/then/than/
Cheers,
Peter
> + the value of '#mux-control-cells'.
>
> Optionally, mux controller nodes can also specify the state the mux should
> have when it is idle. The idle-state property is used for this. If the
> @@ -67,6 +69,8 @@ select:
> pattern: '^mux-controller'
> - required:
> - '#mux-control-cells'
> + - required:
> + - '#mux-state-cells'
>
> properties:
> $nodename:
> @@ -75,6 +79,9 @@ properties:
> '#mux-control-cells':
> enum: [ 0, 1 ]
>
> + '#mux-state-cells':
> + enum: [ 1, 2 ]
> +
> idle-state:
> $ref: /schemas/types.yaml#/definitions/int32
> minimum: -2
> @@ -179,4 +186,21 @@ examples:
> };
> };
> };
> +
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + mux1: mux-controller {
> + compatible = "gpio-mux";
> + #mux-state-cells = <1>;
> + mux-gpios = <&exp_som 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + transceiver4: can-phy4 {
> + compatible = "ti,tcan1042";
> + #phy-cells = <0>;
> + max-bitrate = <5000000>;
> + standby-gpios = <&exp_som 7 GPIO_ACTIVE_HIGH>;
> + mux-states = <&mux1 1>;
> + };
> ...
>
On Tue, 30 Nov 2021 17:48:46 +0530, Aswath Govindraju wrote:
> In some cases, it is required to provide the state to which the mux
> controller has be set to, from the consumer device tree node. Document the
> property mux-states that can be used for adding this support.
>
> Signed-off-by: Aswath Govindraju <[email protected]>
> ---
> .../devicetree/bindings/mux/gpio-mux.yaml | 11 ++++++--
> .../devicetree/bindings/mux/mux-consumer.yaml | 14 ++++++++++
> .../bindings/mux/mux-controller.yaml | 26 ++++++++++++++++++-
> 3 files changed, 48 insertions(+), 3 deletions(-)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mux/mux-controller.example.dt.yaml: can-phy4: 'mux-states' does not match any of the regexes: 'pinctrl-[0-9]+'
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1561624
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
On Tue, Nov 30, 2021 at 05:48:46PM +0530, Aswath Govindraju wrote:
> In some cases, it is required to provide the state to which the mux
> controller has be set to, from the consumer device tree node. Document the
> property mux-states that can be used for adding this support.
I having a hard time understanding why you need this. One consumer
configures a mux one way and another consumer another way? How do you
arbitrate that? Please elaborate on what 'some cases' are and why it's
required.
Can't you just add a cell for the 'state' allowing for 1-2 cells
instead of 0-1?
> Signed-off-by: Aswath Govindraju <[email protected]>
> ---
> .../devicetree/bindings/mux/gpio-mux.yaml | 11 ++++++--
> .../devicetree/bindings/mux/mux-consumer.yaml | 14 ++++++++++
> .../bindings/mux/mux-controller.yaml | 26 ++++++++++++++++++-
> 3 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.yaml b/Documentation/devicetree/bindings/mux/gpio-mux.yaml
> index 0a7c8d64981a..ee4de9fbaf4d 100644
> --- a/Documentation/devicetree/bindings/mux/gpio-mux.yaml
> +++ b/Documentation/devicetree/bindings/mux/gpio-mux.yaml
> @@ -26,7 +26,10 @@ properties:
> List of gpios used to control the multiplexer, least significant bit first.
>
> '#mux-control-cells':
> - const: 0
> + enum: [ 0, 1 ]
> +
> + '#mux-state-cells':
> + enum: [ 1, 2 ]
>
> idle-state:
> default: -1
> @@ -34,7 +37,11 @@ properties:
> required:
> - compatible
> - mux-gpios
> - - "#mux-control-cells"
> +anyOf:
> + - required:
> + - "#mux-control-cells"
> + - required:
> + - "#mux-state-cells"
>
> additionalProperties: false
>
> diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> index 7af93298ab5c..64f353714227 100644
> --- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> @@ -25,6 +25,11 @@ description: |
> strings to label each of the mux controllers listed in the "mux-controls"
> property.
>
> + If it is required to provide the state that the mux controller needs to
> + be set to, the property "mux-states" must be used. An optional property
> + "mux-state-names" can be used to provide a list of strings, to label
> + each of the mux controllers listed in the "mux-states" property.
> +
> mux-ctrl-specifier typically encodes the chip-relative mux controller number.
> If the mux controller chip only provides a single mux controller, the
> mux-ctrl-specifier can typically be left out.
> @@ -35,12 +40,21 @@ properties:
> mux-controls:
> $ref: /schemas/types.yaml#/definitions/phandle-array
>
> + mux-states:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> mux-control-names:
> description:
> Devices that use more than a single mux controller can use the
> "mux-control-names" property to map the name of the requested mux
> controller to an index into the list given by the "mux-controls" property.
>
> + mux-state-names:
> + description:
> + Devices that use more than a single mux controller can use the
> + "mux-state-names" property to map the name of the requested mux
> + controller to an index into the list given by the "mux-states" property.
> +
> additionalProperties: true
>
> ...
> diff --git a/Documentation/devicetree/bindings/mux/mux-controller.yaml b/Documentation/devicetree/bindings/mux/mux-controller.yaml
> index 736a84c3b6a5..b29dbf521f01 100644
> --- a/Documentation/devicetree/bindings/mux/mux-controller.yaml
> +++ b/Documentation/devicetree/bindings/mux/mux-controller.yaml
> @@ -25,7 +25,9 @@ description: |
> --------------------
>
> Mux controller nodes must specify the number of cells used for the
> - specifier using the '#mux-control-cells' property.
> + specifier using the '#mux-control-cells' or 'mux-state-cells'
> + property. Value of '#mux-state-cells' will always be one greater then
> + the value of '#mux-control-cells'.
>
> Optionally, mux controller nodes can also specify the state the mux should
> have when it is idle. The idle-state property is used for this. If the
> @@ -67,6 +69,8 @@ select:
> pattern: '^mux-controller'
> - required:
> - '#mux-control-cells'
> + - required:
> + - '#mux-state-cells'
>
> properties:
> $nodename:
> @@ -75,6 +79,9 @@ properties:
> '#mux-control-cells':
> enum: [ 0, 1 ]
>
> + '#mux-state-cells':
> + enum: [ 1, 2 ]
> +
> idle-state:
> $ref: /schemas/types.yaml#/definitions/int32
> minimum: -2
> @@ -179,4 +186,21 @@ examples:
> };
> };
> };
> +
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + mux1: mux-controller {
> + compatible = "gpio-mux";
> + #mux-state-cells = <1>;
> + mux-gpios = <&exp_som 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + transceiver4: can-phy4 {
> + compatible = "ti,tcan1042";
> + #phy-cells = <0>;
> + max-bitrate = <5000000>;
> + standby-gpios = <&exp_som 7 GPIO_ACTIVE_HIGH>;
> + mux-states = <&mux1 1>;
> + };
> ...
> --
> 2.17.1
>
>
On 2021-11-30 21:14, Rob Herring wrote:
> On Tue, Nov 30, 2021 at 05:48:46PM +0530, Aswath Govindraju wrote:
>> In some cases, it is required to provide the state to which the mux
>> controller has be set to, from the consumer device tree node. Document the
>> property mux-states that can be used for adding this support.
>
> I having a hard time understanding why you need this. One consumer
> configures a mux one way and another consumer another way? How do you
> arbitrate that? Please elaborate on what 'some cases' are and why it's
> required.
>
> Can't you just add a cell for the 'state' allowing for 1-2 cells
> instead of 0-1?
A mux controller can control several muxes. That happens e.g. when the
same gpio lines are connected to several mux chips in parallel. When
you operate one mux, the other parallel muxes just follow along. If
these muxes are then used orthogonally, coordination is needed. The real
world case I had was I2C and an analog signal connected to an ADC that
went through parallel/dependent muxes like this. It is simply not
possible to freely mux the I2C bus and the analog signal, they are tied
together and dependent and must coordinate their accesses.
The addition now is that Aswath wants a mux control client to "point
at" a single state instead of the whole mux control, and I see that as
a usable addition. It seems like a natural place to specify a single mux
state that some driver needs in some circumstance.
But, since a mux control is inherently a shared resource (see above),
one consumer might need a specific state and some other consumer might
need the whole mux control and manage the states as e.g. the existing
i2c-mux-gpmux binding is doing. So, you need to be able to specify both
ways to point at muxes; either to a single mux state, or to the whole mux
control.
While you could make the extra cell optional, that does not work for
the mux/adi,adg792a binding, since it is using the #mux-control-cells
property to determine which mode it should operate its three muxes in.
Either with one common/parallel mux control, or with three independent
mux controls.
So, that binding is already in the 0-1 territory, and adding an optional
extra cell makes it 0-1-2 with no way to determine what is intended when
the cell count is 1 (three independent mux controls OR one mux control
and a state). I see no way to add the extra state to that binding, short
of adding an extra property somewhere for that driver, but I simply did
not want to go that path because it would get inconsistent when trying
to add that in a backwards compatible way. Or rather, that was my
conclusion.
Suggestions welcome...
Cheers,
Peter
Hi Rob,
On 01/12/21 2:18 am, Peter Rosin wrote:
>
>
> On 2021-11-30 21:14, Rob Herring wrote:
>> On Tue, Nov 30, 2021 at 05:48:46PM +0530, Aswath Govindraju wrote:
>>> In some cases, it is required to provide the state to which the mux
>>> controller has be set to, from the consumer device tree node. Document the
>>> property mux-states that can be used for adding this support.
>>
>> I having a hard time understanding why you need this. One consumer
>> configures a mux one way and another consumer another way? How do you
>> arbitrate that? Please elaborate on what 'some cases' are and why it's
>> required.
>>
>> Can't you just add a cell for the 'state' allowing for 1-2 cells
>> instead of 0-1?
>
> A mux controller can control several muxes. That happens e.g. when the
> same gpio lines are connected to several mux chips in parallel. When
> you operate one mux, the other parallel muxes just follow along. If
> these muxes are then used orthogonally, coordination is needed. The real
> world case I had was I2C and an analog signal connected to an ADC that
> went through parallel/dependent muxes like this. It is simply not
> possible to freely mux the I2C bus and the analog signal, they are tied
> together and dependent and must coordinate their accesses.
>
> The addition now is that Aswath wants a mux control client to "point
> at" a single state instead of the whole mux control, and I see that as
> a usable addition. It seems like a natural place to specify a single mux
> state that some driver needs in some circumstance.
>
> But, since a mux control is inherently a shared resource (see above),
> one consumer might need a specific state and some other consumer might
> need the whole mux control and manage the states as e.g. the existing
> i2c-mux-gpmux binding is doing. So, you need to be able to specify both
> ways to point at muxes; either to a single mux state, or to the whole mux
> control.
>
> While you could make the extra cell optional, that does not work for
> the mux/adi,adg792a binding, since it is using the #mux-control-cells
> property to determine which mode it should operate its three muxes in.
> Either with one common/parallel mux control, or with three independent
> mux controls.
>
> So, that binding is already in the 0-1 territory, and adding an optional
> extra cell makes it 0-1-2 with no way to determine what is intended when
> the cell count is 1 (three independent mux controls OR one mux control
> and a state). I see no way to add the extra state to that binding, short
> of adding an extra property somewhere for that driver, but I simply did
> not want to go that path because it would get inconsistent when trying
> to add that in a backwards compatible way. Or rather, that was my
> conclusion.
>
> Suggestions welcome...
>
In addition to what Peter has mentioned, I would like to elaborate on my
use case for adding this feature. I am trying to implement this feature
in the TCAN104x transceiver driver, for selecting the mux state to route
the signals from CAN controller to transceivers on the board. The state
of the mux line to be set, can change based on the design and this is
needs to be provided from the device tree. Hence, I am trying to add
this support for providing the state to be set to the driver from the
device tree node.
Also, one more question on regarding DT check errors, may I know what
should be the order in which the patches need to be posted in order to
not get the error? This is because mux-states would be a new property to
be added in the TCAN104x bindings and I thought that it would need to be
posted after the patch for the changes in mux-controller are merged.
Thanks,
Aswath
> Cheers,
> Peter
>
On Tue, Nov 30, 2021 at 10:32 PM Aswath Govindraju <[email protected]> wrote:
>
> Hi Rob,
>
> On 01/12/21 2:18 am, Peter Rosin wrote:
> >
> >
> > On 2021-11-30 21:14, Rob Herring wrote:
> >> On Tue, Nov 30, 2021 at 05:48:46PM +0530, Aswath Govindraju wrote:
> >>> In some cases, it is required to provide the state to which the mux
> >>> controller has be set to, from the consumer device tree node. Document the
> >>> property mux-states that can be used for adding this support.
> >>
> >> I having a hard time understanding why you need this. One consumer
> >> configures a mux one way and another consumer another way? How do you
> >> arbitrate that? Please elaborate on what 'some cases' are and why it's
> >> required.
> >>
> >> Can't you just add a cell for the 'state' allowing for 1-2 cells
> >> instead of 0-1?
> >
> > A mux controller can control several muxes. That happens e.g. when the
> > same gpio lines are connected to several mux chips in parallel. When
> > you operate one mux, the other parallel muxes just follow along. If
> > these muxes are then used orthogonally, coordination is needed. The real
> > world case I had was I2C and an analog signal connected to an ADC that
> > went through parallel/dependent muxes like this. It is simply not
> > possible to freely mux the I2C bus and the analog signal, they are tied
> > together and dependent and must coordinate their accesses.
> >
> > The addition now is that Aswath wants a mux control client to "point
> > at" a single state instead of the whole mux control, and I see that as
> > a usable addition. It seems like a natural place to specify a single mux
> > state that some driver needs in some circumstance.
> >
> > But, since a mux control is inherently a shared resource (see above),
> > one consumer might need a specific state and some other consumer might
> > need the whole mux control and manage the states as e.g. the existing
> > i2c-mux-gpmux binding is doing. So, you need to be able to specify both
> > ways to point at muxes; either to a single mux state, or to the whole mux
> > control.
> >
> > While you could make the extra cell optional, that does not work for
> > the mux/adi,adg792a binding, since it is using the #mux-control-cells
> > property to determine which mode it should operate its three muxes in.
> > Either with one common/parallel mux control, or with three independent
> > mux controls.
> >
> > So, that binding is already in the 0-1 territory, and adding an optional
> > extra cell makes it 0-1-2 with no way to determine what is intended when
> > the cell count is 1 (three independent mux controls OR one mux control
> > and a state). I see no way to add the extra state to that binding, short
> > of adding an extra property somewhere for that driver, but I simply did
> > not want to go that path because it would get inconsistent when trying
> > to add that in a backwards compatible way. Or rather, that was my
> > conclusion.
> >
> > Suggestions welcome...
> >
>
>
> In addition to what Peter has mentioned, I would like to elaborate on my
> use case for adding this feature. I am trying to implement this feature
> in the TCAN104x transceiver driver, for selecting the mux state to route
> the signals from CAN controller to transceivers on the board. The state
> of the mux line to be set, can change based on the design and this is
> needs to be provided from the device tree. Hence, I am trying to add
> this support for providing the state to be set to the driver from the
> device tree node.
Okay, please add something along the lines of what Peter said for when
you use which binding.
> Also, one more question on regarding DT check errors, may I know what
> should be the order in which the patches need to be posted in order to
> not get the error? This is because mux-states would be a new property to
> be added in the TCAN104x bindings and I thought that it would need to be
> posted after the patch for the changes in mux-controller are merged.
Looks like a circular dependency. Assuming you ran dt_binding_check on
the series, just add a note about the dependency and I won't send the
report.
Rob