[i2c] [patch 2.6.19-rc6 0/11] I2C driver model updates

[Jean Delvare]

On Fri, 15 Dec 2006 09:55:42 -0800, David Brownell wrote:
> On Friday 15 December 2006 8:51 am, Jean Delvare wrote:
> > Hi David,
> > 
> > On Sat, 25 Nov 2006 13:40:41 -0800, David Brownell wrote:
> > > Here's a refresh of some previous patches, updated per feedback, and
> > > headed by some new core cleanups.
> > > 
> > > The first few should IMO be candidates for 2.6.20-early:
> > > 
> > >  - Core cleanup:  remove i2c_adapter.dev and non-class "i2c-adapter" class
> > >  - i2-isa updates, it (needlessly) relied on those interfaces
> > >  - I2C adapter updates, use i2c_adapter.class_dev.dev not &i2c_adapter.dev
> > >  - I2C misc updates, non-adapter drivers need the same changes.
> > 
> > There's an organizational problem in this series. Each patch must
> > constitute an incremental update where everything still compiles and
> > works afterwards.
> 
> That is certainly the ideal; but as I'm sure you know, sometimes
> patchsets get in where "works afterwards" holds after the whole
> series but not individual patches (and thus "git bisect" loses).
> 
> That's especially true with API changes, which often can't be
> done in digestible/reviewable chunks without such breakage.
> 
> Those particular patches started out with that "API change"; later
> I noticed it wasn't needed in this case, which can be a LOT nicer.

These cases should be rare, and I don't think we are in such a case
here. The incremental path exists, it'll just need some more work.

> > But then there's another problem in patch #3: 
> > this patch doesn't only remove users of i2c_adapter.dev, it also
> > changes the way adapters declare their parent device. This family of
> > changes really belongs to the i2c-core patch (#1), as one cannot go
> > without the other.
> 
> Well, #3 should be split in two:  (a) the "remove users", which is most
> of it, and (b) the change-init bits.  With (b) going with old #1, not (a),
> to preserve the "still runs after each patch" rule.

Yes, exactly.

> > So, please rework this first patchset into something that I can apply
> > incrementally.
> 
> OK.  And one that applies on top of 2.6.19-rc1 too.  Cleanups to
> the i2c-nforce and it87 driver needed a bit of attention; also the
> class device changes affected i2c-dev.

2.6.20-rc1, please ;) it87 should be easy, the offending code was
simply dropped as far as I can see. i2c-nforce2 needs some attention,
yes. And so do the new drivers.

It also seems to me that your patchset forgot a significant number of
drivers, most notably in drivers/media. Some grepping suggests that the
following drivers may need changes:

drivers/media/common/saa7146_i2c.c
drivers/media/dvb/dvb-usb/cxusb.c
drivers/media/dvb/dvb-usb/dibusb-common.c
drivers/media/dvb/dvb-usb/digitv.c
drivers/media/dvb/dvb-usb/dib0700_core.c
drivers/media/dvb/dvb-usb/dib0700_devices.c
drivers/media/dvb/dvb-usb/ttusb2.c
drivers/media/dvb/pluto2/pluto2.c
drivers/media/video/bt8xx/bttv-i2c.c
drivers/media/video/ir-kbd-i2c.c
drivers/media/video/cx88/cx88-i2c.c
drivers/media/video/cx88/cx88-vp3054-i2c.c
drivers/media/video/em28xx/em28xx-i2c.c
drivers/media/video/saa7134/saa7134-i2c.c
drivers/video/fb_ddc.c
drivers/w1/masters/ds2482.c

Thanks,
-- 
Jean Delvare