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;
Feedback-ID: i68a1478a:Fastmail
Date:   Mon, 1 Aug 2022 11:12:00 -0500
From:   Patrick Williams <patrick@stwcx.xyz>
To:     Andy Shevchenko <andy.shevchenko@gmail.com>
Cc:     Potin Lai <potin.lai.pt@gmail.com>,
        Jonathan Cameron <jic23@kernel.org>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Potin Lai <potin.lai@quantatw.com>,
        linux-iio <linux-iio@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 2/2] iio: humidity: hdc100x: add manufacturer and
 device ID check
Message-ID: <Yuf7UAVrIJCnO40X@heinlein.stwcx.org.github.beta.tailscale.net>
References: <20220728125435.3336618-1-potin.lai.pt@gmail.com>
 <20220728125435.3336618-3-potin.lai.pt@gmail.com>
 <20220731130959.50826fc4@jic23-huawei>
 <4ea235d1-46c1-87de-760f-dc4775007ae0@gmail.com>
 <CAHp75VcZqTpmvVV=u4t=fdx=ffzksoWVDFZmq6Lfr6DrFrB2aA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="Gjd1qHuI9vRoQdHR"
Content-Disposition: inline
In-Reply-To: <CAHp75VcZqTpmvVV=u4t=fdx=ffzksoWVDFZmq6Lfr6DrFrB2aA@mail.gmail.com>
Precedence: bulk


--Gjd1qHuI9vRoQdHR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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@gmail.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 add=
ress,
> > and we want to use multiple compatibles to support both chips with sing=
le device
> > node in device tree.
> >
> > Ex:
> > compatible =3D "ti,hdc1099", "silabs,si7020";
>=20
> 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.

>=20
> > 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 driv=
er
> > (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 ou=
r case?
>=20
> If I may advise... fix your DT by dropping the wrong compatible item.

This doesn't really give any helpful advice.

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?

--=20
Patrick Williams

--Gjd1qHuI9vRoQdHR
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEBGD9ii4LE9cNbqJBqwNHzC0AwRkFAmLn+04ACgkQqwNHzC0A
wRlfTQ//amKYKmMJr6Mt4WHMpVSsZLyIFAM08NxGUnDkF/8jJ9z+PUWKcsSuiwnf
VjRdBYnliOA83OA0JSgwFQcTFWyJ8pIZ85aiI+nDqzkS7yPhdOY6Y7O2wBFmM+Fo
mUuHDyJx997lVWL7pjSkSwi718ejEjeKvkuZmxlOF79SCh6L63TH93FzO6xcSwyI
e9mUOYq/BR4DSW+HWSJVHenBOOU8EZHcHxtP+fHrrk8QGz2KAIS01XdySYscZCgf
woK1ndpaMovHOKNT9qrUX21/FaCYqz8z01W0WEEU5KriH3Eg7b1/wNek3jVSNKau
PRfi3HDIS7TXWK37QV+JgO5lYplj3zZl7C3ij+7+Wz6V6fNywh4OIpCJL7QAWZdp
2DL2x0K8rjOABV3HSPvyby9DdR7RUFJ+x9+uUW22vJEe0XBD8YZhFCmXDXgqWzA8
9tmEmqZVwZZpyQESKRyKq3uP6ZaZl1hn6qDK8NCgXZMbdbWm2sb9PYHJEtEFyMNu
xOPLKGRte39XaD/fXL8d4PnRatt37VdImOepN/FUPyyCM66mUwb7Sv0bHik22+/e
Vq+Cv70o5emWQFnMmmiNItlHWJxpQS/R2Btshdr79Zzv8W9XvVTE/q5hRjzAD71F
Tq6xWsfclzIyeBaTCB1rmTzjvGwWBqZ9JSS7lcRWR+0uE6WveDM=
=iSnM
-----END PGP SIGNATURE-----

--Gjd1qHuI9vRoQdHR--