[i2c] [patch 2.6.21-rc3-git +i2c 2/5] i2c stack can remove()

[David Brownell]

On Tuesday 13 March 2007 12:01 pm, Jean Delvare wrote:

> I've been converting i2c-parport + lm90 to experiment with the new
> model, but I'm hitting a bug in i2c_unregister_device. ...
> 
> 	...
> 
> It's obviously not correct to call i2c_device_remove explicitly and
> then have i2c_detach_client call it again, but I am a bit confused on
> how to fix it. 

Yeah, I was puzzling over that again with that last cleanup patch
I sent yesterday:  the one removing i2c_client.list (and its
sibling i2c_adapter.clients).  I think the problem I noticed with
that is this same problem.


> Why do we need this explicit call to i2c_device_remove 
> in the first place, as it appears that i2c_detach_client does it just
> fine? 

I was trying to remember that, but my thought processes from
early November aren't so fresh in my mind any more.  :)

Most likely the right answer is to have i2c_unregister_device()
just call device_unregister() and have that be the end of the
story ... modulo i2c_client.list and i2c_client.usage_count
issues.  The "normal" path should NOT involve that completion
stuff, and driver model refcounting should just do the right
thing without trying to synchronize anything.


> If we really want to do that, then I guess we need to set 
> client->dev.driver to NULL between the two blocks so that the second
> call to i2c_device_remove takes the quick exit?

The underlying puzzlee that I recall is the refcounting.  I
agree it's done wrong now.  I'll have to look at what the
right fix should be.

- Dave