[i2c] [patch/rfc 2.6.21-rc3-git +i2c 0/4] remove some driver-model/i2c-core duplication

[David Brownell]

On Wednesday 14 March 2007 11:25 am, Jean Delvare wrote:
>
> >  - i2c_client.driver vanishes ... i2c_client.dev.driver suffices
> >  - i2c_client.adapter vanishes ... i2c_client.dev.parent suffices
> >  - i2c_adapter.list vanishes ... i2c_adapter_class.devices suffices
> >  - i2c_client.list vanishes ... i2c_adapter.dev.klist_children suffices
> > 
> > These go on top of the previous i2c cleanup and driver model patches
> > I've sent.  I think the first two are closest to being "done", other
> > than their excessive size.  The last two don't feel cooked yet
> 
> With regards to the first two patches, I think it was quite natural to
> have an adapter an a driver pointers directly in struct i2c_client in
> the old model. 

Key word:  "was".  Before the driver model, back in 2.5.early.  :)


> My plan is to give people the time to move to the new 
> model, this should remove a lot of uses of these redundant pointers.
> Then we can see what's remaining and fix that, it should result in much
> smaller patches.

Actually there are a number of uses that could change right now,
before drivers change to "new style" usage and stop needing to
initialize i2c_client.{adapter,driver} directly.

 
> One thing I am worried about though, is that for the drivers I had to
> update, the change did not really look like a cleanup. It was making
> things more complex, not more simple.

More so for i2c_client.adapter than the driver field, because of
the no-inlines-yet issue.

This is a bit of a tradeoff; "simpler" means more or less "no type
conversions needed", but the cost is more complexity (and scope for
bugs) in the core.


> That makes the removal of these 
> pointers questionable. At the very least we would probably need to
> provide inline functions to make the code look better, but we also need
> to make sure that the overall operation doesn't increase the drivers
> size in practice.

Re inlines, I had much the same thought for accessing the adapter.
It's not much of an issue for the driver field though; drivers don't
need to access that after initialization, except when they hack some
diagnostic strings together ... or maybe invoke command().

Code size difference should be attributable entirely to one pointer
offset for i2c adapter access:  adapter == client->field + offset in
both cases, but "previously" offset was zero.  

 
> The last two patches, OTOH, are local to i2c-core so I am fine with
> merging them quickly. Except that we have to get rid of i2c-isa first,
> as was demonstrated earlier. So right now my action plan looks like:
> 
> * Stop using i2c-isa (9 drivers or so left)
> * Kill i2c-isa
> * Kill i2c_adapter.list (patch 3 in this series)
> * Kill i2c_client.list (patch 4 in this series)

Actually I see that i2c-isa would only be directly affected
by #4 ... 

- Dave