[lm-sensors]

[khali@linux-fr.org (Jean Delvare)]

Hi Mauro,

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

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
changes happening.

> 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
> CodingStyle).

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

Thanks,
-- 
Jean Delvare