Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220906082820.4030401-1-martyn.welch@collabora.co.uk>
 <20220906082820.4030401-2-martyn.welch@collabora.co.uk> <Yxc6zptiJEf2TzP5@smile.fi.intel.com>
 <CACRpkdZHKEW+WJAdCCf2DN7gN+ZM7pFpeSXfccB508N4=-LkoQ@mail.gmail.com> <YxdI/TLBrzJP3RKi@smile.fi.intel.com>
In-Reply-To: <YxdI/TLBrzJP3RKi@smile.fi.intel.com>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Tue, 6 Sep 2022 15:33:34 +0200
Message-ID: <CACRpkdaQ+0wbreyCEaoBnjKT0rtgPEnotZQw_Eh=y4xktwrwHQ@mail.gmail.com>
Subject: Re: [PATCH v2 2/5] dt-bindings: gpio: pca95xx: add entry for pcal6534
 and PI4IOE5V6534Q
To:     Andy Shevchenko <andriy.shevchenko@intel.com>
Cc:     Martyn Welch <martyn.welch@collabora.co.uk>,
        Bartosz Golaszewski <brgl@bgdev.pl>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Martyn Welch <martyn.welch@collabora.com>,
        Krzysztof Kozlowski <krzk@kernel.org>,
        linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Sep 6, 2022 at 3:20 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
> On Tue, Sep 06, 2022 at 03:08:00PM +0200, Linus Walleij wrote:
> > On Tue, Sep 6, 2022 at 2:19 PM Andy Shevchenko
> > <andriy.shevchenko@intel.com> wrote:
> > > On Tue, Sep 06, 2022 at 09:28:16AM +0100, Martyn Welch wrote:
> > > > From: Martyn Welch <martyn.welch@collabora.com>
> > > >
> > > > The NXP PCAL6534 is a 34-bit I2C I/O expander similar to the PCAL6524. The
> > > > Diodes PI4IOE5V6534Q is a functionally identical chip provided by Diodes
> > > > Inc.
> > >
> > > ...
> > >
> > > > +    oneOf:
> > > > +      - items:
> > > > +        - const: diodes,pi4ioe5v6534q
> > > > +        - const: nxp,pcal6534
> > >
> > > ^^^
> > >
> > > > +      - items:
> > > > +        - enum:
> > >
> > > > +          - nxp,pcal6534
> > >
> > > ^^^
> > >
> > > Not sure why is this dup?
> >
> > No that is how DT compatibles work. One version of the component,
> > bought from NXP will look like this:
> >
> > compatible = "nxp,pcal6534";
> >
> > Another version bought from diodes will look like this:
> >
> > compatible = "diodes,pi4ioe5v6534q", "nxp,pcal6534";
> >
> > Then the drivers are probed matching from left to right,
> > with the "most compatible" matching first.
> >
> > This also answers your question on the implementation.
>
> Then I don't understand why the const list above is only for new chips
> and not for the old one where the same can be applied.

That's YAML. It's because the const list is the most compact way
to express two precise items following after each other, and the enum
list is an implicit list of single-item const:s, as you cannot enum
tuples.

> Mysterious ways of DT...

It's not DT, it's YAML that is mysterious. DT itself is a pretty
straight-forward
grammar, while YAML is a meta-grammar describing the DT grammar
(ML stands for Meta Language).

All meta languages are mysterious.

Yours,
Linus Walleij