[PATCH] i2c driver changes for 2.5.64

[greg@kroah.com (Greg KH)]

On Mon, Mar 17, 2003 at 09:28:41PM -0500, Mark D. Studebaker  wrote:
> >If so, any hope of merging the two to make it at least sane?  :)
> >
> 
> sounds like more trouble than it is worth;
> hard to move files in CVS without losing the history.

True, but it seems strange to have files in two different repositories.
But I now see why you did that because of the 2.4 code, right?  Anyway,
I'll live :)

> >>The biggest thing remaining to do in CVS is tackling
> >>the PCI drivers. Approx. 20 of our 60 drivers are PCI.
> >
> >
> >Where are these drivers?  I only see 17 instances of pci_module_init()
> >in the lm_sensors2 cvs tree.  Are these the ones?  If you look at
> >2.5.65, 3 ones were added from the cvs tree (and converted to work
> >properly with the pci code.)  I see there are only 5 drivers in the main
> >kernel tree that use pci_module_init() so a number more still need to be
> >moved into there.
> >
> 
> right. Plus a couple more in chips/ that don't call pci_module_init
> (sis5595, vt8231). Minus the ones already in 2.5 (I see that
> 2.5.65 added your patch with 3 more) leaves about 15.
> 
> My point was the ~40 non-PCI drivers should go a lot more easily;
> Kyosti already did a lot of cleanup on those.

Good, I haven't really looked at them yet.

> >>I'd like to keep sensors CVS 2.4-compatible, or at least
> >>delay a branch as long as possible. Kyosti was working
> >>on getting to the point that we could submit a patch
> >>to 2.4 (until we do that, CVS is incompatible with stock 2.4
> >>kernels because of the i2c_driver struct change).
> >
> >
> >Why care about backwards compatibility?  Hopefully there will not need
> >to be a cvs tree for the kernel portions of the i2c code if we get all
> >of the code into the main kernel tree.
> >
> 
> We have a large number of 2.4-based "customers". Our project is
> ranked in the top 100 on freshmeat (no idea if that means anything, though 
> :)
> If our 2.7.0 release last December was the last 2.4-compatible release,
> how bad is that? I don't know. Unless we get a patch into 2.4, it will be,
> because of the i2c_driver struct change that's already been made in CVS.
> I'm guessing we want to release 2.4-compatible packages for another year?

You've already forked the cvs tree, right?  What's keeping you from just
staying with this fork for the 2.4 code?

> But maybe that's hopelessly ambitious. Maybe 2.7.0 will have to be it.
> Kyosti was optimistic that on the lm_sensors side (as opposed to i2c),
> we could stay compatible with 2.4 and 2.5 in one branch. But he
> hasn't been heard from in a while...

I'm not so sure about that due to the driver model changes, but am not
certain yet.  I'll shut up now until I get some more code done...

thanks,

greg k-h