[lm-sensors] Re: [PATCH 06/16] i2c: ID redefinition cleanups, 2 of 2
khali at linux-fr.org
Thu Oct 27 23:08:35 CEST 2005
> From V4L side of view it would be better if we wait until 2.6.17 for
> the newer I2C core, since, our goal to 2.6.15 is to include, with
> experimental status, several newer boards like: em28xx based USB boards
> (already on V4L tree), WinTV PVR USB2, ivtv and maybe usbvision. 2.6.16
> should be reserved for bug fixing these devices and cleaning up USB
You may decide that there will be no new v4l driver in 2.6.16, the
choice is up to you, but you can't force other maintainers to stop any
non-bugfix change for 6 or 8 week.
And there is nothing like "the newer I2C core". There are continuous
> IMHO, it is not a good idea to change I2C interface during the
> merging stuff (since lots of efforts should be made to fix
> incompatibitilies and having them all using almost the same
You know, i2c changes don't only affect media/video drivers. They also
affect i2c bus drivers, including framebuffer I2C/DDC support, almost
all hardware monitoring drivers, and a number of platform-specific
drivers. I can't wait for all these areas to stop their development
before I submit a change to the i2c core.
I don't see how "lots of efforts" would be needed to deal with this.
Almost all changes will trigger a warning or compilation error if a
given driver wasn't updated accordingly, so we'll notice soon enough.
And most fixes after that are one-liners. It is also well known that
you have to pay particular attention to new drivers because they might
slip through mass changes. This ain't specific to the media/video
drivers, nor to i2c.
> We have to take care with this... otherwise some patches will break the
> other's patches.
This happens all the time, and there's nothing to be afraid of. Broken
patches can be fixed. If this is a problem for you, I suspect you are
not using the adequate tools.
(Subliminal hint: quilt rocks.)
More information about the lm-sensors