On Sun, 15 Feb 2026 20:00:52 +0200 Erikas Bitovtas <[email protected]> wrote:
> On 2/15/26 7:49 PM, Jonathan Cameron wrote: > > On Sat, 14 Feb 2026 10:44:23 -0600 > > David Lechner <[email protected]> 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? > > > > 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
