[i2c] [patch 2.6.19-rc6 7/11] i2c driver remove()

[David Brownell]

On Monday 04 December 2006 1:57 pm, Scott Wood wrote:
> On Sat, Nov 25, 2006 at 03:01:24PM -0800, David Brownell wrote:
> > @@ -341,8 +381,16 @@ int i2c_del_adapter(struct i2c_adapter *
> >  	 * it can fail; in which case we give up. */
> >  	list_for_each_safe(item, _n, &adap->clients) {
> >  		client = list_entry(item, struct i2c_client, list);
> > +		driver = client->driver;
> > +
> > +		/* new style */
> > +		if (!driver || driver->remove) {
> > +			i2c_unregister_device(client);
> > +			continue;
> > +		}
> 
> Is client->driver supposed to be set for new-style devices? 

Not always ... one of the canonical operating modes in the driver
model is to have a device nodescreated, and then have its driver
bound *MUCH* later, e.g. by "hotplug" event processing.  That
requires such a "device may not have a driver" state.  But when
it's got a driver, I was expecting the i2c core to basically
act the same as it does now.

That said, client->driver is not necessary, or arguably even
appropriate, given client->dev.driver.  Removing client->driver
is one of several driver model cleanups I didn't do.  In the
past, we've had problems with driver stacks (like USB) that
didn't keep such parallel state exactly in sync... the notion
of parallel state is error prone.


> The above 
> (along with several other places like it) indicates it's at least a
> possibility, but i2c_del_driver will call a NULL detach_client() if
> client->driver is set.

Clearly I didn't see that particuar problem.  How would that happen?
I see a test for "client->driver != driver", which should succeed in
all cases where client->driver is null.  Would this be a case where
the driver got _reloaded_ since nothing is nulling client->driver
after the first detach_client() call?  That shouldn't be possible
with new-style devices/drivers.

- Dave