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/[email protected]/
>>
>> 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!
