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
