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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 1, 2022 at 6:26 PM Andy Shevchenko
<andy.shevchenko@xxxxxxxxx> wrote:
> On Mon, Aug 1, 2022 at 6:12 PM Patrick Williams <patrick@xxxxxxxxx> 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@xxxxxxxxx> 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



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux