[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025081711-coral-aardwark-9f061b@boujee-and-buff>
Date: Sun, 17 Aug 2025 12:37:57 -0400
From: Ben Collins <ben.collins@...ux.dev>
To: David Lechner <dlechner@...libre.com>
Cc: Jonathan Cameron <jic23@...nel.org>, Ben Collins <bcollins@...ter.com>,
Nuno Sá <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Andrew Hepp <andrew.hepp@...pp.dev>, linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] dt-bindings: iio: mcp9600: Add compatible for
microchip,mcp9601
On Sat, Aug 16, 2025 at 01:55:31PM -0500, David Lechner wrote:
> On 8/16/25 4:58 AM, Jonathan Cameron wrote:
> > On Fri, 15 Aug 2025 16:46:03 +0000
> > Ben Collins <bcollins@...ter.com> wrote:
> >
> >> The mcp9600 driver supports the mcp9601 chip, but complains about not
> >> recognizing the device id on probe. A separate patch...
> >>
> >> iio: mcp9600: Recognize chip id for mcp9601
> >>
> >> ...addresses this. This patch updates the dt-bindings for this chip to
> >> reflect the change to allow explicitly setting microchip,mcp9601 as
> >> the expected chip type.
> >>
> >> The mcp9601 also supports features not found on the mcp9600, so this
> >> will also allow the driver to differentiate the support of these
> >> features.
> >
> > If it's additional features only then you can still use a fallback
> > compatible. Intent being that a new DT vs old kernel still 'works'.
> >
> > Then for the driver on new kernels we match on the new compatible and
> > support those new features. Old kernel users get to keep the ID
> > mismatch warning - they can upgrade if they want that to go away ;)
> >
> > Krzysztof raised the same point on v2 but I'm not seeing it addressed
> > in that discussion.
>
> One could make the argument that these are not entirely fallback
> compatible since bit 4 of the STATUS register has a different
> meaning depending on if the chip is MCP9601/L01/RL01 or not.
There are some nuances to this register between the two, but it can be
used generically as "not in range" for both.
My understanding from the docs is if VSENSE is connected on mcp9601,
then it is explicitly open-circuit detection vs. short-circuit, which
is bit 5.
> Interestingly, the existing bindings include interrupts for
> open circuit and short circuit alert pins. But these pins
> also only exist on MCP9601/L01/RL01. If we decide these aren't
> fallback compatible, then those properties should have the
> proper constraints added as well.
In my v4 patch, I'm going to remove the short/open circuit interrupts
since they are not implemented, yet.
I have VSENSE wired on my board so I can work on those interrupts and
register support in a later patch series.
--
Ben Collins
https://libjwt.io
https://github.com/benmcollins
--
3EC9 7598 1672 961A 1139 173A 5D5A 57C7 242B 22CF
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists