[lkml]   [2016]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] dt-bindings: i2c: add bindings for nxp,pca9541
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 <>
>>>> ---
>>>> .../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

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

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...


 \ /
  Last update: 2016-07-06 16:21    [W:0.059 / U:1.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site