linux-kernel - Re: [PATCH v5 2/2] iio: humidity: hdc100x: add manufacturer and device ID check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VfOPgDbTdt1EXJ5+exGXCZeT9VdtcOUDt_g4fn20S2Qwg@mail.gmail.com>
Date:   Mon, 1 Aug 2022 18:30:16 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Patrick Williams <patrick@...cx.xyz>
Cc:     Potin Lai <potin.lai.pt@...il.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Potin Lai <potin.lai@...ntatw.com>,
        linux-iio <linux-iio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 2/2] iio: humidity: hdc100x: add manufacturer and
 device ID check

On Mon, Aug 1, 2022 at 6:26 PM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
> On Mon, Aug 1, 2022 at 6:12 PM Patrick Williams <patrick@...cx.xyz> wrote:
> > On Mon, Aug 01, 2022 at 10:22:16AM +0200, Andy Shevchenko wrote:
> > > On Mon, Aug 1, 2022 at 3:52 AM Potin Lai <potin.lai.pt@...il.com> wrote:
> > > > On 7/31/22 20:09, Jonathan Cameron wrote:
> > > > In our hardware board, we have "ti,hdc1080" as main source, and "silabs,si7020"
> > > > for 2nd source. This two chip are locate at same bus and same slave address,
> > > > and we want to use multiple compatibles to support both chips with single device
> > > > node in device tree.
> > > >
> > > > Ex:
> > > > compatible = "ti,hdc1099", "silabs,si7020";
> > >
> > > This is simply broken DT, you must not put incompatible hardware on
> > > the same compatible string. DT is by definition the description of a
> > > certain platform. What you showed is a combination of incompatible
> > > chips in a single DT.
> >
> > We were mistaken that this is the appropriate way to specify this
> > behavior, partially because it works as long as the probe functions
> > return an error the next matching driver from the compatible will probe.
> > It does seem that specifying two different compatibles like this would
> > violate the intention of the DT spec:
> >
> >     The property value consists of a concatenated list of null terminated
> >     strings, from most specific to most general. They allow a device to
> >     express its compatibility with a family of similar devices, potentially
> >     allowing a single device driver to match against several devices.
> >
> > >
> > > > In order to support this, I need to add ID checking mechanism into the current
> > > > hdc100x driver, so the si7020 chip will fail to probe with hdc100x driver
> > > > (because the ID checking is not failed), then success probe with si7020.
> > > >
> > > > Base on you explanation, it looks multiple compatibles is not suitable in this
> > > > case? Would you mind advise us what would be the better approach for our case?
> > >
> > > If I may advise... fix your DT by dropping the wrong compatible item.
> >
> > This doesn't really give any helpful advice.
>
> Sorry to hear this, but it's the best and correct solution to your
> problem. Believe me, many Linux people will tell you the same.
>
> > The reality is that these two chips are pin compatible and function
> > compatible but not driver compatible.  Boards have been manufactured
> > which are identical except for this chip replaced, due various to chip
> > shortages.
> >
> > Making probe fail so that the next 'compatible' is chosen sounds like it
> > isn't desired.  I'm pretty sure you can't have two DT entries for the
> > same i2c address, but with different 'compatible" properties, and even
> > if we did you'd still need probe to fail on one of them.
> >
> > Are there any other suggestions for being able to inform the kernel that
> > one of two chips might be present?

Btw, how would it be solved in ACPI is the playing status bits by
firmware, depending on the run-time detected environment (straps,
other means). So, you may fix it on bootloader / firmware level by
patching DTB with status okay / disabled. I believe in DTB is the
number, which can be easily binary patched.

> I guess there is a gap in understanding what DT is. DT is the
> description of the *platform*. Changing any discrete component on the
> platform is changing the platform.


-- 
With Best Regards,
Andy Shevchenko