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.0

On Tue, Feb 10, 2026 at 10:46:10PM +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. 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.

There was CM36686 v1 and v2, so I do not understand versioning here.
Also, lack of any changelog.

And how is it supposed to work for us? Try yourself:

  $ b4 diff 20260210-cm36686-v1-1-aef68dd46ad4@gmail.com
  Could not find lower series to compare against.

Please implement previous feedback.

Best regards,
Krzysztof

On 2/11/26 8:49 AM, Krzysztof Kozlowski wrote:
> 
> There was CM36686 v1 and v2, so I do not understand versioning here.
> Also, lack of any changelog.
> 
> And how is it supposed to work for us? Try yourself:
> 
>   $ b4 diff 20260210-cm36686-v1-1-aef68dd46ad4@gmail.com
>   Could not find lower series to compare against.
> 
> Please implement previous feedback.
> 
> Best regards,
> Krzysztof
> 

Since I am making changes to the existing driver instead of creating a new one,
I introduced a new patch series. As I mentioned in the cover letter, cm36686 is
fully compatible with vcnl4040, so instead of creating a new binding, I create a
fallback compatible for the device. I probably should have named this patch
series something else.
As for the previous feedback, I added the subject prefix and removed the
redundant phrasing.

On 11/02/2026 11:07, Erikas Bitovtas wrote:
> 
> 
> On 2/11/26 8:49 AM, Krzysztof Kozlowski wrote:
>>
>> There was CM36686 v1 and v2, so I do not understand versioning here.
>> Also, lack of any changelog.
>>
>> And how is it supposed to work for us? Try yourself:
>>
>>   $ b4 diff 20260210-cm36686-v1-1-aef68dd46ad4@gmail.com
>>   Could not find lower series to compare against.

Look here.

>>
>> Please implement previous feedback.
>>
>> Best regards,
>> Krzysztof
>>
> 
> Since I am making changes to the existing driver instead of creating a new one,
> I introduced a new patch series. As I mentioned in the cover letter, cm36686 is
> fully compatible with vcnl4040, so instead of creating a new binding, I create a
> fallback compatible for the device. I probably should have named this patch
> series something else.

That's fine, but that's v3 of previous patches. Your work was to add
CM36686 support. How you do it, evolves, but patchset/work is one
continuous work. When you rework approach next time, you also start from
v1? And then you go back to previous solution of new driver it will jump
from v1 to v3?

> As for the previous feedback, I added the subject prefix and removed the
> redundant phrasing.

And how do I know it if there is no changelog with list of changes? Look
how many patches is here:
https://lore.kernel.org/linux-devicetree/

Best regards,
Krzysztof

>>>
>>> Please implement previous feedback.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>> Since I am making changes to the existing driver instead of creating a new one,
>> I introduced a new patch series. As I mentioned in the cover letter, cm36686 is
>> fully compatible with vcnl4040, so instead of creating a new binding, I create a
>> fallback compatible for the device. I probably should have named this patch
>> series something else.
> 
> That's fine, but that's v3 of previous patches. Your work was to add
> CM36686 support. How you do it, evolves, but patchset/work is one
> continuous work. When you rework approach next time, you also start from
> v1? And then you go back to previous solution of new driver it will jump
> from v1 to v3?
> 

There has been a misunderstanding. I assumed that since I will no longer
be developing that driver, this warrants a new patch series. I apologize
for this.
Here is the changelog since v2:
- Remove the previous unnecessary proposed driver and bindings.
- Add a fallback compatible for cm36686 of vcnl4040.
- Add a new compatible for cm36672p.
- Add channel info for cm36672p.
- Remove redundant information in the dt-bindings commit message.
Here is the link to v2:
https://lore.kernel.org/linux-iio/20260209182432.00006c3c@huawei.com/

I have received some feedback regarding the changes I made to the
existing vcnl4000 driver. Shall I submit the implementation of it as a
v3 to that series of patches?

On Wed, Feb 11, 2026 at 03:32:41PM +0200, Erikas Bitovtas wrote:

> >>> Please implement previous feedback.
> >>
> >> Since I am making changes to the existing driver instead of creating a new one,
> >> I introduced a new patch series. As I mentioned in the cover letter, cm36686 is
> >> fully compatible with vcnl4040, so instead of creating a new binding, I create a
> >> fallback compatible for the device. I probably should have named this patch
> >> series something else.
> > 
> > That's fine, but that's v3 of previous patches. Your work was to add
> > CM36686 support. How you do it, evolves, but patchset/work is one
> > continuous work. When you rework approach next time, you also start from
> > v1? And then you go back to previous solution of new driver it will jump
> > from v1 to v3?
> > 
> 
> There has been a misunderstanding. I assumed that since I will no longer
> be developing that driver, this warrants a new patch series. I apologize
> for this.
> Here is the changelog since v2:
> - Remove the previous unnecessary proposed driver and bindings.
> - Add a fallback compatible for cm36686 of vcnl4040.
> - Add a new compatible for cm36672p.
> - Add channel info for cm36672p.
> - Remove redundant information in the dt-bindings commit message.
> Here is the link to v2:
> https://lore.kernel.org/linux-iio/20260209182432.00006c3c@huawei.com/
> 
> I have received some feedback regarding the changes I made to the
> existing vcnl4000 driver. Shall I submit the implementation of it as a
> v3 to that series of patches?

I guess v4 would be better as this is assumed misversioned v3, if I got
the situation correctly.

-- 
With Best Regards,
Andy Shevchenko

On 2/11/26 3:37 PM, Andy Shevchenko wrote:
> On Wed, Feb 11, 2026 at 03:32:41PM +0200, Erikas Bitovtas wrote:
> 
>>>>> Please implement previous feedback.
>>>>
>>>> Since I am making changes to the existing driver instead of creating a new one,
>>>> I introduced a new patch series. As I mentioned in the cover letter, cm36686 is
>>>> fully compatible with vcnl4040, so instead of creating a new binding, I create a
>>>> fallback compatible for the device. I probably should have named this patch
>>>> series something else.
>>>
>>> That's fine, but that's v3 of previous patches. Your work was to add
>>> CM36686 support. How you do it, evolves, but patchset/work is one
>>> continuous work. When you rework approach next time, you also start from
>>> v1? And then you go back to previous solution of new driver it will jump
>>> from v1 to v3?
>>>
>>
>> There has been a misunderstanding. I assumed that since I will no longer
>> be developing that driver, this warrants a new patch series. I apologize
>> for this.
>> Here is the changelog since v2:
>> - Remove the previous unnecessary proposed driver and bindings.
>> - Add a fallback compatible for cm36686 of vcnl4040.
>> - Add a new compatible for cm36672p.
>> - Add channel info for cm36672p.
>> - Remove redundant information in the dt-bindings commit message.
>> Here is the link to v2:
>> https://lore.kernel.org/linux-iio/20260209182432.00006c3c@huawei.com/
>>
>> I have received some feedback regarding the changes I made to the
>> existing vcnl4000 driver. Shall I submit the implementation of it as a
>> v3 to that series of patches?
> 
> I guess v4 would be better as this is assumed misversioned v3, if I got
> the situation correctly.
> 

Yes, I started a new patch series when I should have continued previous
one. I will submit an implementation of your feedback as a v4 to the
patch series I started initially. Thank you!

On Wed, Feb 11, 2026 at 03:44:37PM +0200, Erikas Bitovtas wrote:
> On 2/11/26 3:37 PM, Andy Shevchenko wrote:
> > On Wed, Feb 11, 2026 at 03:32:41PM +0200, Erikas Bitovtas wrote:

...

> >>>>> Please implement previous feedback.
> >>>>
> >>>> Since I am making changes to the existing driver instead of creating a new one,
> >>>> I introduced a new patch series. As I mentioned in the cover letter, cm36686 is
> >>>> fully compatible with vcnl4040, so instead of creating a new binding, I create a
> >>>> fallback compatible for the device. I probably should have named this patch
> >>>> series something else.
> >>>
> >>> That's fine, but that's v3 of previous patches. Your work was to add
> >>> CM36686 support. How you do it, evolves, but patchset/work is one
> >>> continuous work. When you rework approach next time, you also start from
> >>> v1? And then you go back to previous solution of new driver it will jump
> >>> from v1 to v3?
> >>>
> >>
> >> There has been a misunderstanding. I assumed that since I will no longer
> >> be developing that driver, this warrants a new patch series. I apologize
> >> for this.
> >> Here is the changelog since v2:
> >> - Remove the previous unnecessary proposed driver and bindings.
> >> - Add a fallback compatible for cm36686 of vcnl4040.
> >> - Add a new compatible for cm36672p.
> >> - Add channel info for cm36672p.
> >> - Remove redundant information in the dt-bindings commit message.
> >> Here is the link to v2:
> >> https://lore.kernel.org/linux-iio/20260209182432.00006c3c@huawei.com/
> >>
> >> I have received some feedback regarding the changes I made to the
> >> existing vcnl4000 driver. Shall I submit the implementation of it as a
> >> v3 to that series of patches?
> > 
> > I guess v4 would be better as this is assumed misversioned v3, if I got
> > the situation correctly.
> 
> Yes, I started a new patch series when I should have continued previous
> one. I will submit an implementation of your feedback as a v4 to the
> patch series I started initially. Thank you!

Do not forget to include the _full_ changelog per version

  ...from v<N>:
  ...
  ...from v2:
  ...
  ...from v1:
  ...

-- 
With Best Regards,
Andy Shevchenko