On Sun, 15 Feb 2026 18:16:45 +0200 Erikas Bitovtas <[email protected]> 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 <[email protected]> > >>>>>> --- > >>>>>> .../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 >
