* [PATCH] dt-bindings: i2c: add bindings for nxp,pca9541
@ 2016-06-27 10:11 Peter Rosin
2016-06-27 13:17 ` Guenter Roeck
0 siblings, 1 reply; 6+ messages in thread
From: Peter Rosin @ 2016-06-27 10:11 UTC (permalink / raw)
To: devicetree
Cc: Peter Rosin, Wolfram Sang, Rob Herring, Mark Rutland,
Andrew Morton, David S. Miller, Greg Kroah-Hartman, Kalle Valo,
Mauro Carvalho Chehab, Jiri Slaby, Guenter Roeck, linux-i2c,
open list
Fill the gap for this pre-existing driver.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../devicetree/bindings/i2c/i2c-arb-pca9541.txt | 33 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt
Hi!
I'm wondering about this driver. It is not a trivial device, and yet it
has historically relied on the i2c core matching the chip w/o vendor
prefix. This is not ideal. But what to do about the driver implementing
this in terms of an i2c-mux, somthing which the chip is not; It is an
i2c arbitrator. It just happens to rely on the i2c mux core also handling
i2c gates and i2c arbitrators. But that seems like a Linux detail. So I
don't know what to do here?
That is, the patch - as is - describes something that would be trivial to
support today, but at the same time it seems to be too tied to Linux.
The problem is that the i2c@0 intermediate node is not really needed, but
at the same time removing it would cause a disruption for the driver since
it can't really use the i2c mux core if that node isn't there. I don't
see a simple way to fix that in the i2c mux core either (but admittedly
haven't given it too much thought).
Any suggestions?
Cheers,
Peter
PS. The driver source is in drivers/i2c/muxes/i2c-mux-pca9541.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt
new file mode 100644
index 000000000000..edbe84935906
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt
@@ -0,0 +1,33 @@
+* NXP PCA9541 I2C bus master selector
+
+Required Properties:
+
+ - compatible: Must be "nxp,pca9541"
+
+ - reg: The I2C address of the device.
+
+ The following required properties are defined externally:
+
+ - Standard I2C mux properties. See i2c-mux.txt in this directory.
+ - I2C child bus nodes. See i2c-mux.txt in this directory.
+
+
+Example:
+
+ i2c-arbitrator@74 {
+ compatible = "nxp,pca9541";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x74>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ eeprom@54 {
+ compatible = "at,24c08";
+ reg = <0x54>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index e1b090f86e0d..3dd44d0d166c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5521,6 +5521,7 @@ S: Maintained
F: Documentation/i2c/i2c-topology
F: Documentation/i2c/muxes/
F: Documentation/devicetree/bindings/i2c/i2c-mux*
+F: Documentation/devicetree/bindings/i2c/i2c-arb*
F: drivers/i2c/i2c-mux.c
F: drivers/i2c/muxes/
F: include/linux/i2c-mux.h
--
2.1.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] dt-bindings: i2c: add bindings for nxp,pca9541
2016-06-27 10:11 [PATCH] dt-bindings: i2c: add bindings for nxp,pca9541 Peter Rosin
@ 2016-06-27 13:17 ` Guenter Roeck
2016-06-27 16:27 ` Peter Rosin
0 siblings, 1 reply; 6+ messages in thread
From: Guenter Roeck @ 2016-06-27 13:17 UTC (permalink / raw)
To: Peter Rosin, devicetree
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Andrew Morton,
David S. Miller, Greg Kroah-Hartman, Kalle Valo,
Mauro Carvalho Chehab, Jiri Slaby, linux-i2c, open list
On 06/27/2016 03:11 AM, Peter Rosin wrote:
> Fill the gap for this pre-existing driver.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> .../devicetree/bindings/i2c/i2c-arb-pca9541.txt | 33 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt
>
> Hi!
>
> I'm wondering about this driver. It is not a trivial device, and yet it
> has historically relied on the i2c core matching the chip w/o vendor
> prefix. This is not ideal. But what to do about the driver implementing
> this in terms of an i2c-mux, somthing which the chip is not; It is an
> i2c arbitrator. It just happens to rely on the i2c mux core also handling
> i2c gates and i2c arbitrators. But that seems like a Linux detail. So I
> don't know what to do here?
>
The concept of arbitrators didn't exist when I wrote the driver. I would not
have a problem with renaming the file if that is what you are asking for.
> That is, the patch - as is - describes something that would be trivial to
> support today, but at the same time it seems to be too tied to Linux.
>
> The problem is that the i2c@0 intermediate node is not really needed, but
> at the same time removing it would cause a disruption for the driver since
> it can't really use the i2c mux core if that node isn't there. I don't
> see a simple way to fix that in the i2c mux core either (but admittedly
> haven't given it too much thought).
>
The gpio arbitrator uses the same principle as well. Why not just leave it
alone ? Besides, I think it is a good idea to have it, since it groups
the i2c devices behind the chip together. I would not consider that to be
a Linuxism, but a design choice.
Guenter
> Any suggestions?
>
> Cheers,
> Peter
>
> PS. The driver source is in drivers/i2c/muxes/i2c-mux-pca9541.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt
> new file mode 100644
> index 000000000000..edbe84935906
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt
> @@ -0,0 +1,33 @@
> +* NXP PCA9541 I2C bus master selector
> +
> +Required Properties:
> +
> + - compatible: Must be "nxp,pca9541"
> +
> + - reg: The I2C address of the device.
> +
> + The following required properties are defined externally:
> +
> + - Standard I2C mux properties. See i2c-mux.txt in this directory.
> + - I2C child bus nodes. See i2c-mux.txt in this directory.
> +
> +
> +Example:
> +
> + i2c-arbitrator@74 {
> + compatible = "nxp,pca9541";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x74>;
> +
> + i2c@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + eeprom@54 {
> + compatible = "at,24c08";
> + reg = <0x54>;
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e1b090f86e0d..3dd44d0d166c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5521,6 +5521,7 @@ S: Maintained
> F: Documentation/i2c/i2c-topology
> F: Documentation/i2c/muxes/
> F: Documentation/devicetree/bindings/i2c/i2c-mux*
> +F: Documentation/devicetree/bindings/i2c/i2c-arb*
> F: drivers/i2c/i2c-mux.c
> F: drivers/i2c/muxes/
> F: include/linux/i2c-mux.h
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] dt-bindings: i2c: add bindings for nxp,pca9541
2016-06-27 13:17 ` Guenter Roeck
@ 2016-06-27 16:27 ` Peter Rosin
2016-07-01 1:20 ` Rob Herring
0 siblings, 1 reply; 6+ messages in thread
From: Peter Rosin @ 2016-06-27 16:27 UTC (permalink / raw)
To: Guenter Roeck, devicetree
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Andrew Morton,
David S. Miller, Greg Kroah-Hartman, Kalle Valo,
Mauro Carvalho Chehab, Jiri Slaby, linux-i2c, open list
On 2016-06-27 15:17, Guenter Roeck wrote:
> On 06/27/2016 03:11 AM, Peter Rosin wrote:
>> Fill the gap for this pre-existing driver.
>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>> ---
>> .../devicetree/bindings/i2c/i2c-arb-pca9541.txt | 33 ++++++++++++++++++++++
>> MAINTAINERS | 1 +
>> 2 files changed, 34 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt
>>
>> Hi!
>>
>> I'm wondering about this driver. It is not a trivial device, and yet it
>> has historically relied on the i2c core matching the chip w/o vendor
>> prefix. This is not ideal. But what to do about the driver implementing
>> this in terms of an i2c-mux, somthing which the chip is not; It is an
>> i2c arbitrator. It just happens to rely on the i2c mux core also handling
>> i2c gates and i2c arbitrators. But that seems like a Linux detail. So I
>> don't know what to do here?
>>
>
> The concept of arbitrators didn't exist when I wrote the driver. I would not
> have a problem with renaming the file if that is what you are asking for.
No, that was not my issue, I just wanted to document bindings for pca9541,
and I didn't like how it turned out.
I don't really care if the bindings doc is named i2c-mux-pca9541.txt (that
would match the name of the driver, but it still wouldn't make the chip a mux).
>> That is, the patch - as is - describes something that would be trivial to
>> support today, but at the same time it seems to be too tied to Linux.
>>
>> The problem is that the i2c@0 intermediate node is not really needed, but
>> at the same time removing it would cause a disruption for the driver since
>> it can't really use the i2c mux core if that node isn't there. I don't
>> see a simple way to fix that in the i2c mux core either (but admittedly
>> haven't given it too much thought).
>>
>
> The gpio arbitrator uses the same principle as well. Why not just leave it
> alone ? Besides, I think it is a good idea to have it, since it groups
> the i2c devices behind the chip together. I would not consider that to be
> a Linuxism, but a design choice.
The grouping argument would make sense if there was anything outside the
group. Also, the required reg property and the extra #address-cells and
#size-cells doesn't add anything and just gets in the way, and is indeed
the result of Linuxisms leaking back into device trees.
If there were no muxes and this was a new driver, the example bindings
would almost certainly have been something like:
i2c-arbitrator@74 {
compatible = "nxp,pca9541";
reg = <0x74>;
#address-cells = <1>;
#size-cells = <0>;
eeprom@54 {
compatible = "at,24c08";
reg = <0x54>;
};
};
which I find much nicer.
But, I can't find a way to implement that and keep backwards compatibility
with old existing device trees.
Which is why I submitted the patch I did. It documents the pca9541 bindings,
something which is lacking, in terms of i2c-mux as the driver is written.
At the same time, this feels ugly and exposes linuxism and I wanted to make
that clear up front. The above simply looks better than the example in the
patch.
I intended to mark the submission [RFC PATCH], but I now realize that that
went missing along the way, sorry.
Cheers,
Peter
> Guenter
>
>> Any suggestions?
>>
>> Cheers,
>> Peter
>>
>> PS. The driver source is in drivers/i2c/muxes/i2c-mux-pca9541.c
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt
>> new file mode 100644
>> index 000000000000..edbe84935906
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt
>> @@ -0,0 +1,33 @@
>> +* NXP PCA9541 I2C bus master selector
>> +
>> +Required Properties:
>> +
>> + - compatible: Must be "nxp,pca9541"
>> +
>> + - reg: The I2C address of the device.
>> +
>> + The following required properties are defined externally:
>> +
>> + - Standard I2C mux properties. See i2c-mux.txt in this directory.
>> + - I2C child bus nodes. See i2c-mux.txt in this directory.
>> +
>> +
>> +Example:
>> +
>> + i2c-arbitrator@74 {
>> + compatible = "nxp,pca9541";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0x74>;
>> +
>> + i2c@0 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> +
>> + eeprom@54 {
>> + compatible = "at,24c08";
>> + reg = <0x54>;
>> + };
>> + };
>> + };
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index e1b090f86e0d..3dd44d0d166c 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -5521,6 +5521,7 @@ S: Maintained
>> F: Documentation/i2c/i2c-topology
>> F: Documentation/i2c/muxes/
>> F: Documentation/devicetree/bindings/i2c/i2c-mux*
>> +F: Documentation/devicetree/bindings/i2c/i2c-arb*
>> F: drivers/i2c/i2c-mux.c
>> F: drivers/i2c/muxes/
>> F: include/linux/i2c-mux.h
>>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] dt-bindings: i2c: add bindings for nxp,pca9541
2016-06-27 16:27 ` Peter Rosin
@ 2016-07-01 1:20 ` Rob Herring
2016-07-06 10:12 ` Peter Rosin
0 siblings, 1 reply; 6+ messages in thread
From: Rob Herring @ 2016-07-01 1:20 UTC (permalink / raw)
To: Peter Rosin
Cc: Guenter Roeck, devicetree, Wolfram Sang, Mark Rutland,
Andrew Morton, David S. Miller, Greg Kroah-Hartman, Kalle Valo,
Mauro Carvalho Chehab, Jiri Slaby, linux-i2c, open list
On Mon, Jun 27, 2016 at 06:27:21PM +0200, Peter Rosin wrote:
> On 2016-06-27 15:17, Guenter Roeck wrote:
> > On 06/27/2016 03:11 AM, Peter Rosin wrote:
> >> Fill the gap for this pre-existing driver.
> >>
> >> Signed-off-by: Peter Rosin <peda@axentia.se>
> >> ---
> >> .../devicetree/bindings/i2c/i2c-arb-pca9541.txt | 33 ++++++++++++++++++++++
> >> MAINTAINERS | 1 +
> >> 2 files changed, 34 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt
> >>
> >> Hi!
> >>
> >> I'm wondering about this driver. It is not a trivial device, and yet it
> >> has historically relied on the i2c core matching the chip w/o vendor
> >> prefix. This is not ideal. But what to do about the driver implementing
> >> this in terms of an i2c-mux, somthing which the chip is not; It is an
> >> i2c arbitrator. It just happens to rely on the i2c mux core also handling
> >> i2c gates and i2c arbitrators. But that seems like a Linux detail. So I
> >> don't know what to do here?
> >>
> >
> > The concept of arbitrators didn't exist when I wrote the driver. I would not
> > have a problem with renaming the file if that is what you are asking for.
>
> No, that was not my issue, I just wanted to document bindings for pca9541,
> and I didn't like how it turned out.
>
> I don't really care if the bindings doc is named i2c-mux-pca9541.txt (that
> would match the name of the driver, but it still wouldn't make the chip a mux).
So name it i2c-pca9541.txt or the somewhat standard nxp,pca9541.txt
following the compatible.
>
> >> That is, the patch - as is - describes something that would be trivial to
> >> support today, but at the same time it seems to be too tied to Linux.
> >>
> >> The problem is that the i2c@0 intermediate node is not really needed, but
> >> at the same time removing it would cause a disruption for the driver since
> >> it can't really use the i2c mux core if that node isn't there. I don't
> >> see a simple way to fix that in the i2c mux core either (but admittedly
> >> haven't given it too much thought).
> >>
> >
> > The gpio arbitrator uses the same principle as well. Why not just leave it
> > alone ? Besides, I think it is a good idea to have it, since it groups
> > the i2c devices behind the chip together. I would not consider that to be
> > a Linuxism, but a design choice.
>
> The grouping argument would make sense if there was anything outside the
> group. Also, the required reg property and the extra #address-cells and
> #size-cells doesn't add anything and just gets in the way, and is indeed
> the result of Linuxisms leaking back into device trees.
>
> If there were no muxes and this was a new driver, the example bindings
> would almost certainly have been something like:
>
> i2c-arbitrator@74 {
> compatible = "nxp,pca9541";
> reg = <0x74>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> eeprom@54 {
> compatible = "at,24c08";
> reg = <0x54>;
> };
> };
>
> which I find much nicer.
Yes.
> But, I can't find a way to implement that and keep backwards compatibility
> with old existing device trees.
I don't see any in the kernel tree nor is it documented, so there is not
compatibility to worry about.
>
> Which is why I submitted the patch I did. It documents the pca9541 bindings,
> something which is lacking, in terms of i2c-mux as the driver is written.
> At the same time, this feels ugly and exposes linuxism and I wanted to make
> that clear up front. The above simply looks better than the example in the
> patch.
>
> I intended to mark the submission [RFC PATCH], but I now realize that that
> went missing along the way, sorry.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] dt-bindings: i2c: add bindings for nxp,pca9541
2016-07-01 1:20 ` Rob Herring
@ 2016-07-06 10:12 ` Peter Rosin
2016-07-06 15:12 ` Guenter Roeck
0 siblings, 1 reply; 6+ messages in thread
From: Peter Rosin @ 2016-07-06 10:12 UTC (permalink / raw)
To: Rob Herring
Cc: Guenter Roeck, devicetree, Wolfram Sang, Mark Rutland,
Andrew Morton, David S. Miller, Greg Kroah-Hartman, Kalle Valo,
Mauro Carvalho Chehab, Jiri Slaby, linux-i2c, open list
On 2016-07-01 03:20, Rob Herring wrote:
> On Mon, Jun 27, 2016 at 06:27:21PM +0200, Peter Rosin wrote:
>> On 2016-06-27 15:17, Guenter Roeck wrote:
>>> On 06/27/2016 03:11 AM, Peter Rosin wrote:
>>>> Fill the gap for this pre-existing driver.
>>>>
>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>>> ---
>>>> .../devicetree/bindings/i2c/i2c-arb-pca9541.txt | 33 ++++++++++++++++++++++
>>>> MAINTAINERS | 1 +
>>>> 2 files changed, 34 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt
>>>>
>>>> Hi!
>>>>
>>>> I'm wondering about this driver. It is not a trivial device, and yet it
>>>> has historically relied on the i2c core matching the chip w/o vendor
>>>> prefix. This is not ideal. But what to do about the driver implementing
>>>> this in terms of an i2c-mux, somthing which the chip is not; It is an
>>>> i2c arbitrator. It just happens to rely on the i2c mux core also handling
>>>> i2c gates and i2c arbitrators. But that seems like a Linux detail. So I
>>>> don't know what to do here?
>>>>
>>>
>>> The concept of arbitrators didn't exist when I wrote the driver. I would not
>>> have a problem with renaming the file if that is what you are asking for.
>>
>> No, that was not my issue, I just wanted to document bindings for pca9541,
>> and I didn't like how it turned out.
>>
>> I don't really care if the bindings doc is named i2c-mux-pca9541.txt (that
>> would match the name of the driver, but it still wouldn't make the chip a mux).
>
> So name it i2c-pca9541.txt or the somewhat standard nxp,pca9541.txt
> following the compatible.
>
>>
>>>> That is, the patch - as is - describes something that would be trivial to
>>>> support today, but at the same time it seems to be too tied to Linux.
>>>>
>>>> The problem is that the i2c@0 intermediate node is not really needed, but
>>>> at the same time removing it would cause a disruption for the driver since
>>>> it can't really use the i2c mux core if that node isn't there. I don't
>>>> see a simple way to fix that in the i2c mux core either (but admittedly
>>>> haven't given it too much thought).
>>>>
>>>
>>> The gpio arbitrator uses the same principle as well. Why not just leave it
>>> alone ? Besides, I think it is a good idea to have it, since it groups
>>> the i2c devices behind the chip together. I would not consider that to be
>>> a Linuxism, but a design choice.
>>
>> The grouping argument would make sense if there was anything outside the
>> group. Also, the required reg property and the extra #address-cells and
>> #size-cells doesn't add anything and just gets in the way, and is indeed
>> the result of Linuxisms leaking back into device trees.
>>
>> If there were no muxes and this was a new driver, the example bindings
>> would almost certainly have been something like:
>>
>> i2c-arbitrator@74 {
>> compatible = "nxp,pca9541";
>> reg = <0x74>;
>>
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> eeprom@54 {
>> compatible = "at,24c08";
>> reg = <0x54>;
>> };
>> };
>>
>> which I find much nicer.
>
> Yes.
>
>> But, I can't find a way to implement that and keep backwards compatibility
>> with old existing device trees.
>
> I don't see any in the kernel tree nor is it documented, so there is not
> compatibility to worry about.
Why do you not care about pre-existing device trees not submitted
to mainline? Is there some statement that DTs are not covered by the
no-regressions-rule?
So, if I instead had submitted the device tree for my boring
one-off-ish hardware that few people will ever use, which uses the
currently working (i.e. as written in my patch) syntax of configuring
the pca9541 in a device tree, then there would be a "user", things
would be set in stone and the DT patch as proposed would be
acceptable?
That is just silly, as I assume you do not want the churn of the
device trees for all kinds of strange one-off devices? Or do you?
We also have to consider the fact that Guenter (who authored the
driver) thinks it's a design choice to have the extra DT level...
Cheers,
Peter
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] dt-bindings: i2c: add bindings for nxp,pca9541
2016-07-06 10:12 ` Peter Rosin
@ 2016-07-06 15:12 ` Guenter Roeck
0 siblings, 0 replies; 6+ messages in thread
From: Guenter Roeck @ 2016-07-06 15:12 UTC (permalink / raw)
To: Peter Rosin, Rob Herring
Cc: devicetree, Wolfram Sang, Mark Rutland, Andrew Morton,
David S. Miller, Greg Kroah-Hartman, Kalle Valo,
Mauro Carvalho Chehab, Jiri Slaby, linux-i2c, open list
On 07/06/2016 03:12 AM, Peter Rosin wrote:
> On 2016-07-01 03:20, Rob Herring wrote:
>> On Mon, Jun 27, 2016 at 06:27:21PM +0200, Peter Rosin wrote:
>>> On 2016-06-27 15:17, Guenter Roeck wrote:
>>>> On 06/27/2016 03:11 AM, Peter Rosin wrote:
>>>>> Fill the gap for this pre-existing driver.
>>>>>
>>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>>>> ---
>>>>> .../devicetree/bindings/i2c/i2c-arb-pca9541.txt | 33 ++++++++++++++++++++++
>>>>> MAINTAINERS | 1 +
>>>>> 2 files changed, 34 insertions(+)
>>>>> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt
>>>>>
>>>>> Hi!
>>>>>
>>>>> I'm wondering about this driver. It is not a trivial device, and yet it
>>>>> has historically relied on the i2c core matching the chip w/o vendor
>>>>> prefix. This is not ideal. But what to do about the driver implementing
>>>>> this in terms of an i2c-mux, somthing which the chip is not; It is an
>>>>> i2c arbitrator. It just happens to rely on the i2c mux core also handling
>>>>> i2c gates and i2c arbitrators. But that seems like a Linux detail. So I
>>>>> don't know what to do here?
>>>>>
>>>>
>>>> The concept of arbitrators didn't exist when I wrote the driver. I would not
>>>> have a problem with renaming the file if that is what you are asking for.
>>>
>>> No, that was not my issue, I just wanted to document bindings for pca9541,
>>> and I didn't like how it turned out.
>>>
>>> I don't really care if the bindings doc is named i2c-mux-pca9541.txt (that
>>> would match the name of the driver, but it still wouldn't make the chip a mux).
>>
>> So name it i2c-pca9541.txt or the somewhat standard nxp,pca9541.txt
>> following the compatible.
>>
>>>
>>>>> That is, the patch - as is - describes something that would be trivial to
>>>>> support today, but at the same time it seems to be too tied to Linux.
>>>>>
>>>>> The problem is that the i2c@0 intermediate node is not really needed, but
>>>>> at the same time removing it would cause a disruption for the driver since
>>>>> it can't really use the i2c mux core if that node isn't there. I don't
>>>>> see a simple way to fix that in the i2c mux core either (but admittedly
>>>>> haven't given it too much thought).
>>>>>
>>>>
>>>> The gpio arbitrator uses the same principle as well. Why not just leave it
>>>> alone ? Besides, I think it is a good idea to have it, since it groups
>>>> the i2c devices behind the chip together. I would not consider that to be
>>>> a Linuxism, but a design choice.
>>>
>>> The grouping argument would make sense if there was anything outside the
>>> group. Also, the required reg property and the extra #address-cells and
>>> #size-cells doesn't add anything and just gets in the way, and is indeed
>>> the result of Linuxisms leaking back into device trees.
>>>
>>> If there were no muxes and this was a new driver, the example bindings
>>> would almost certainly have been something like:
>>>
>>> i2c-arbitrator@74 {
>>> compatible = "nxp,pca9541";
>>> reg = <0x74>;
>>>
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> eeprom@54 {
>>> compatible = "at,24c08";
>>> reg = <0x54>;
>>> };
>>> };
>>>
>>> which I find much nicer.
>>
>> Yes.
>>
>>> But, I can't find a way to implement that and keep backwards compatibility
>>> with old existing device trees.
>>
>> I don't see any in the kernel tree nor is it documented, so there is not
>> compatibility to worry about.
>
> Why do you not care about pre-existing device trees not submitted
> to mainline? Is there some statement that DTs are not covered by the
> no-regressions-rule?
>
> So, if I instead had submitted the device tree for my boring
> one-off-ish hardware that few people will ever use, which uses the
> currently working (i.e. as written in my patch) syntax of configuring
> the pca9541 in a device tree, then there would be a "user", things
> would be set in stone and the DT patch as proposed would be
> acceptable?
>
> That is just silly, as I assume you do not want the churn of the
> device trees for all kinds of strange one-off devices? Or do you?
>
> We also have to consider the fact that Guenter (who authored the
> driver) thinks it's a design choice to have the extra DT level...
>
I don't see the point, I think it hurts readability, and I preferred
to have i2c properties clearly separated from arbiter properties.
Given that the current properties are not broken, I think it is just
a change for the sake of a change. I dislike the notion that changes for
the sake of changes are ok as long as there are no in-kernel uses (after all,
this can go both ways). In short, I don't like it, but then I don't have
to like or approve it either, so that doesn't mean much.
I assume this will be changed for all arbiters, to have a consistent set
of bindings for the same type of devices ? Or will i2c-arb-gpio-challenge
be unmodified since it _does_ have an in-kernel users, and it will be up
to each arbiter to define and implement its own devicetree bindings model ?
Guenter
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-07-06 15:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-27 10:11 [PATCH] dt-bindings: i2c: add bindings for nxp,pca9541 Peter Rosin
2016-06-27 13:17 ` Guenter Roeck
2016-06-27 16:27 ` Peter Rosin
2016-07-01 1:20 ` Rob Herring
2016-07-06 10:12 ` Peter Rosin
2016-07-06 15:12 ` Guenter Roeck
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).