Capella CM36686 is an ambient light and proximity sensor developed by
Capella Microsystems, now a subsidiary of Vishay Intertechnology Inc. It
has an I2C address of 0x60 and is fully compatible with an existing
driver for VCNL4040. Capella CM36672P is a proximity-only sensor that
is fully compatible with CM36686, and therefore with VCNL4040. Add
compatibles for cm36672p and cm36686, with a fallback for cm36686 of
vcnl4040.
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
+ - vishay,vcnl4000
+ - vishay,vcnl4010
+ - vishay,vcnl4020
+ - vishay,vcnl4040
+ - vishay,vcnl4200
+ - items:
+ - const: capella,cm36686
+ - const: vishay,vcnl4040
interrupts:
maxItems: 1
--
2.53.0On Thu, Feb 12, 2026 at 04:42:47PM +0200, Erikas Bitovtas wrote: > Capella CM36686 is an ambient light and proximity sensor developed by > Capella Microsystems, now a subsidiary of Vishay Intertechnology Inc. It > has an I2C address of 0x60 and is fully compatible with an existing > driver for VCNL4040. I wonder why and how... > Capella CM36672P is a proximity-only sensor that > is fully compatible with CM36686, and therefore with VCNL4040. Add > compatibles for cm36672p and cm36686, with a fallback for cm36686 of > vcnl4040. > > 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. > + - vishay,vcnl4000 > + - vishay,vcnl4010 > + - vishay,vcnl4020 > + - vishay,vcnl4040 Best regards, Krzysztof
On 2/13/26 9:54 AM, Krzysztof Kozlowski wrote: > On Thu, Feb 12, 2026 at 04:42:47PM +0200, Erikas Bitovtas wrote: >> Capella CM36686 is an ambient light and proximity sensor developed by >> Capella Microsystems, now a subsidiary of Vishay Intertechnology Inc. It >> has an I2C address of 0x60 and is fully compatible with an existing >> driver for VCNL4040. > > I wonder why and how... VCNL4040 shares the same digital interface as CM36686. All the registers and their fields are the same. It is most likely Vishay just reused the CM36686 design for VCNL4040. > >> Capella CM36672P is a proximity-only sensor that >> is fully compatible with CM36686, and therefore with VCNL4040. Add >> compatibles for cm36672p and cm36686, with a fallback for cm36686 of >> vcnl4040. >> >> 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). >> + - vishay,vcnl4000 >> + - vishay,vcnl4010 >> + - vishay,vcnl4020 >> + - vishay,vcnl4040 > > Best regards, > Krzysztof >
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. Best regards, Krzysztof
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. > Best regards, > Krzysztof
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?
So this would make sense?
- items:
- const: capella,cm36686
- const: vishay,vcnl4040
- const: capella,cm36686p
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) > > 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 > >
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. >> >> 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?
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
On 2/14/26 6:44 PM, David Lechner 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? > > So this would make sense? > > - items: > - const: capella,cm36686 > - const: vishay,vcnl4040 > - const: capella,cm36686p > > If you try to use CM36686 compatible for CM36672P, proximity channels will work, but in_illuminance_raw will return 0 and changing illuminance parameters will have no effect. That is because CM36672P is a proximity sensor only and the register fields for ambient light are reserved. And if you try to use CM36672P compatible with CM36686, it will work, but only proximity channel will be available, even though CM36686 also can sense light.
On 15/02/2026 17:16, Erikas Bitovtas wrote: >> But CM36686 is fully compatible with CM36672P, right? >> >> So this would make sense? >> >> - items: >> - const: capella,cm36686 >> - const: vishay,vcnl4040 >> - const: capella,cm36686p >> >> > If you try to use CM36686 compatible for CM36672P, proximity channels > will work, but in_illuminance_raw will return 0 and changing illuminance > parameters will have no effect. That is because CM36672P is a proximity > sensor only and the register fields for ambient light are reserved. > And if you try to use CM36672P compatible with CM36686, it will work, > but only proximity channel will be available, even though CM36686 also > can sense light. So clearly CM36672P is the superset and should be used with CM36686 fallback. Lack of the fallback how the patch is written now is a mistake. Best regards, Krzysztof
On 2/16/26 9:27 AM, Krzysztof Kozlowski wrote: > On 15/02/2026 17:16, Erikas Bitovtas wrote: >>> But CM36686 is fully compatible with CM36672P, right? >>> >>> So this would make sense? >>> >>> - items: >>> - const: capella,cm36686 >>> - const: vishay,vcnl4040 >>> - const: capella,cm36686p >>> >>> >> If you try to use CM36686 compatible for CM36672P, proximity channels >> will work, but in_illuminance_raw will return 0 and changing illuminance >> parameters will have no effect. That is because CM36672P is a proximity >> sensor only and the register fields for ambient light are reserved. >> And if you try to use CM36672P compatible with CM36686, it will work, >> but only proximity channel will be available, even though CM36686 also >> can sense light. > > So clearly CM36672P is the superset and should be used with CM36686 > fallback. > > Lack of the fallback how the patch is written now is a mistake. > Is it not the other way around? CM36686 compatible fully supports CM36672P, but CM36672P does not fully support CM36686. This would make CM36672P a subset of CM36686, because CM36672P is the proximity sensor, and CM36686 is proximity and ambient light sensor, and therefore, a superset of CM36672P.
On 16/02/2026 09:49, Erikas Bitovtas wrote: > > > On 2/16/26 9:27 AM, Krzysztof Kozlowski wrote: >> On 15/02/2026 17:16, Erikas Bitovtas wrote: >>>> But CM36686 is fully compatible with CM36672P, right? >>>> >>>> So this would make sense? >>>> >>>> - items: >>>> - const: capella,cm36686 >>>> - const: vishay,vcnl4040 >>>> - const: capella,cm36686p >>>> >>>> >>> If you try to use CM36686 compatible for CM36672P, proximity channels >>> will work, but in_illuminance_raw will return 0 and changing illuminance >>> parameters will have no effect. That is because CM36672P is a proximity >>> sensor only and the register fields for ambient light are reserved. >>> And if you try to use CM36672P compatible with CM36686, it will work, >>> but only proximity channel will be available, even though CM36686 also >>> can sense light. >> >> So clearly CM36672P is the superset and should be used with CM36686 >> fallback. >> >> Lack of the fallback how the patch is written now is a mistake. >> > > Is it not the other way around? CM36686 compatible fully supports > CM36672P, but CM36672P does not fully support CM36686. This would make > CM36672P a subset of CM36686, because CM36672P is the proximity sensor, > and CM36686 is proximity and ambient light sensor, and therefore, a > superset of CM36672P. Yes, you are right. The sentence "CM36672P compatible with CM36686" was a bit confusing what is the device what is the compatible. Anyway the commit msg needs changes to clarify reason you chosen vcnl4040 as fallback, even though there is compatibility between CM devices. Best regards, Krzysztof
On Sun, 15 Feb 2026 18:16:45 +0200 Erikas Bitovtas <xerikasxx@gmail.com> wrote: > On 2/14/26 6:44 PM, David Lechner 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? > > > > So this would make sense? > > > > - items: > > - const: capella,cm36686 > > - const: vishay,vcnl4040 > > - const: capella,cm36686p > > > > > If you try to use CM36686 compatible for CM36672P, proximity channels > will work, but in_illuminance_raw will return 0 and changing illuminance > parameters will have no effect. Look at the ordering above. The key I think is it's not saying the cm36672p can fallback to the cm36686, but the other way around. If that fallback was used (because we'd actually had the driver evolve in a different order and older versions only supported the cm36672p) then we'd see a proximity only device presented with the ambient light parts hidden away. > That is because CM36672P is a proximity > sensor only and the register fields for ambient light are reserved. > And if you try to use CM36672P compatible with CM36686, it will work, > but only proximity channel will be available, even though CM36686 also > can sense light. Understood. So in one direction it is correctly considered backwards compatible but not the other way round. The ambient light can be thought of as 'value add' new features on a 'newer' device (obviously that's not actually the case but it's an easier way to think about how fallback compatibles are often used). Jonathan >
© 2016 - 2026 Red Hat, Inc.