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. -- With Best Regards, Andy Shevchenko
