public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Erikas Bitovtas <xerikasxx@gmail.com>
Cc: "David Lechner" <dlechner@baylibre.com>,
	"Krzysztof Kozlowski" <krzk@kernel.org>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Peter Meerwald" <pmeerw@pmeerw.net>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	~postmarketos/upstreaming@lists.sr.ht,
	phone-devel@vger.kernel.org
Subject: Re: [PATCH v4 1/2] dt-bindings: iio: light: vcnl4000: add Capella CM36686 and CM36672P
Date: Sun, 15 Feb 2026 19:38:12 +0000	[thread overview]
Message-ID: <20260215193812.1677d5ea@jic23-huawei> (raw)
In-Reply-To: <38dca0a1-b5a7-45e4-845d-b6bb53203fcb@gmail.com>

On Sun, 15 Feb 2026 20:00:52 +0200
Erikas Bitovtas <xerikasxx@gmail.com> wrote:

> On 2/15/26 7:49 PM, Jonathan Cameron wrote:
> > On Sat, 14 Feb 2026 10:44:23 -0600
> > David Lechner <dlechner@baylibre.com> wrote:
> >   
> >> On 2/13/26 2:56 AM, Erikas Bitovtas wrote:  
> >>>
> >>>
> >>> On 2/13/26 10:51 AM, Krzysztof Kozlowski wrote:    
> >>>> On 13/02/2026 09:29, Erikas Bitovtas wrote:    
> >>>>>>> Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
> >>>>>>> ---
> >>>>>>>  .../devicetree/bindings/iio/light/vishay,vcnl4000.yaml  | 17 +++++++++++------
> >>>>>>>  1 file changed, 11 insertions(+), 6 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/Documentation/devicetree/bindings/iio/light/vishay,vcnl4000.yaml b/Documentation/devicetree/bindings/iio/light/vishay,vcnl4000.yaml
> >>>>>>> index 4d1a225e8868..2ba4d5de4ec4 100644
> >>>>>>> --- a/Documentation/devicetree/bindings/iio/light/vishay,vcnl4000.yaml
> >>>>>>> +++ b/Documentation/devicetree/bindings/iio/light/vishay,vcnl4000.yaml
> >>>>>>> @@ -18,12 +18,17 @@ allOf:
> >>>>>>>  
> >>>>>>>  properties:
> >>>>>>>    compatible:
> >>>>>>> -    enum:
> >>>>>>> -      - vishay,vcnl4000
> >>>>>>> -      - vishay,vcnl4010
> >>>>>>> -      - vishay,vcnl4020
> >>>>>>> -      - vishay,vcnl4040
> >>>>>>> -      - vishay,vcnl4200
> >>>>>>> +    oneOf:
> >>>>>>> +      - enum:
> >>>>>>> +          - capella,cm36672p    
> >>>>>>
> >>>>>> CM36672P is compatible with CM36686, but this is not expressed.
> >>>>>> Confusing commit msg and code.     
> >>>>>
> >>>>> For CM36672P we create a dedicated compatible because it is a
> >>>>> proximity-only sensor which has the same proximity sensor configuration,
> >>>>> but ambient light sensor registers are missing (reserved).    
> >>>>
> >>>> I don't understand this. You just wrote "fully compatible with CM36686"
> >>>> and now you imply that not.
> >>>>
> >>>> Decide.
> >>>>    
> >>> It is not. CM36672P supports only a subset of CM36686 features, in
> >>> particular the proximity sensor. That is what I meant initially.
> >>> I am sorry if the previous phrasing caused any confusion.    
> >>
> >> But CM36686 is fully compatible with CM36672P, right?  
> > 
> > I'd be clear in this discussion that the P version is a subset.
> > So it's very much one way compatibility (your ordering below reflects
> > that right)
> >   
> As I said, only proximity register fields are compatible between
> CM36672P and CM36686. CM36672P lacks ambient light sensing capabilities.
> I am not sure if CM36672P should fall back to VCNL4040, or the other way
> around.

Absolutely could have the vcnl4040 fall back the cm36672p as it would
make a full functioning proximity sensor. Other way around is definitely
not possible as you have noted as the ambient light parts would simply
not work, which is not something we can consider compatible.

I just don't think it makes sense now given the evolution of the binding.

> >>
> >> So this would make sense?
> >>
> >>       - items:
> >>           - const: capella,cm36686
> >>           - const: vishay,vcnl4040
> >>           - const: capella,cm36686p  
> > 
> > I'm not sure we can do that now given we'd also need the option
> > of vcnl4040 falling back to cm36686p for it to feel logical and
> > retrofitting fallbacks is a bit odd.
> > 
> > Jonathan
> >   
> To clarify, there is no such device as CM36686P. I suppose this is
> supposed to be CM36672P here?
Yes. I just didn't check David's list. We only really care about the P
bit meaning proximity only for this discussion.

Thanks,

Jonathan



  reply	other threads:[~2026-02-15 19:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-12 14:42 [PATCH v4 0/2] iio: light: Add support for Capella cm36686 and cm36672p sensors Erikas Bitovtas
2026-02-12 14:42 ` [PATCH v4 1/2] dt-bindings: iio: light: vcnl4000: add Capella CM36686 and CM36672P Erikas Bitovtas
2026-02-13  7:54   ` Krzysztof Kozlowski
2026-02-13  8:29     ` Erikas Bitovtas
2026-02-13  8:51       ` Krzysztof Kozlowski
2026-02-13  8:56         ` Erikas Bitovtas
2026-02-14 16:44           ` David Lechner
2026-02-15 16:16             ` Erikas Bitovtas
2026-02-15 19:35               ` Jonathan Cameron
2026-02-16  7:27               ` Krzysztof Kozlowski
2026-02-16  8:49                 ` Erikas Bitovtas
2026-02-16  9:03                   ` Krzysztof Kozlowski
2026-02-15 17:49             ` Jonathan Cameron
2026-02-15 18:00               ` Erikas Bitovtas
2026-02-15 19:38                 ` Jonathan Cameron [this message]
2026-02-12 14:42 ` [PATCH v4 2/2] iio: light: vcnl4000: add support for " Erikas Bitovtas
2026-02-12 16:20   ` Andy Shevchenko
2026-02-14 18:09   ` Jonathan Cameron
2026-02-15 17:28     ` Erikas Bitovtas
2026-02-15 19:31       ` Jonathan Cameron
2026-02-15 20:06         ` Erikas Bitovtas
2026-02-15 21:55           ` Jonathan Cameron
2026-02-16  8:21             ` Erikas Bitovtas
2026-02-18 19:32               ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260215193812.1677d5ea@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=phone-devel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    --cc=robh@kernel.org \
    --cc=xerikasxx@gmail.com \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox