Re: [PATCH 3/6] i2c: ignore active clients detaching during adapter removal.

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

On Mon, 9 Feb 2009 14:06:42 +0100, Rodolfo Giometti wrote:
> On Fri, Feb 06, 2009 at 10:15:19PM +0100, Jean Delvare wrote:
> > That not the question. We all agree that some i2c chip drivers don't
> > need to be able to prevent the removal of the underlying bus driver.
> > The open point is whether some i2c chip drivers do. Honestly, I don't
> > know, as such cases would happen on embedded systems, which are out of
> > my realm. But maybe David has examples in mind.
> 
> I see. But in this case we should dig into the code and verify what
> each i2c drivers wish to do during driver removal and eventually fix
> it, is that right?

I simply don't know. As I have written above, I do not have any example
of an I2C device which should be allowed to prevent bus removal. But I
am a PC person and the i2c subsystem is used in a very different way on
embedded systems. So better discuss this with people who know these
systems.

> > (...)
> > How does your description differ from the current implementation? I
> > don't follow you.
> 
> Currently an i2c driver may block adpater removal procedure, my
> implementation, instead, considers i2c adapter completely separated
> from i2c clients so that no one can't interfere with adapter
> insertion/removal code.

As far as I can see this only happens for legacy i2c chip drivers,
which implement driver->detach_client() or driver->detach_adapter().
The plan is to get rid of the last few users of this model as soon as
possible, so that's not really relevant.

Do you see any other place in i2c-core where we check for error on
device removal and do something based on that, in particular for
new-style i2c chip drivers?

> > Patches welcome... but I have no clue what you want to do at this point.
> 
> If you agree I can provide a branch tree from current vanilla and
> describe my solution into linux-i2c wiki, so users may test it and
> propose enhancements without touching current stable code.

Well, you can always do that if you want, but please first clearly
define the practical problem you are trying to solve. We are not going
to change the i2c core without a good reason.

Oh, and if you have time to spend on i2c, then helping getting rid of
the remaining legacy drivers would be greatly appreciated. As long as
we have to support both models, there are many core cleanups and
improvements that are simply not possible (or so risky that nobody
wants to try.)

-- 
Jean Delvare