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

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

On Fri, 6 Feb 2009 13:59:07 +0100, Rodolfo Giometti wrote:
> On Fri, Feb 06, 2009 at 01:15:20PM +0100, Jean Delvare wrote:
> > 
> > Taking the old, deprecated, notoriously broken i2c model as an example
> > doesn't necessarily serve your cause ;)
> 
> I see, but till this part is in we should consider it, shouldn't we?
> Eheheh :D

No. As I've said before, ideally I wanted legacy binding style to die
_before_ we add support for multiplexing. But if we don't want to wait,
I still want legacy binding and multiplexing to be mutually exclusive.

> > The big difference, I presume, is that USB is never a system bus. But
> > even for USB, devices can't exist without the host. If you kill the
> > host and resurrect it later, you also kill the devices and resurrect
> > them later.
> 
> But this can be done with i2c devices too! Let's think about leds
> drivers with uses an i2c GPIOs expander, they can exist without any
> adapter, even if they are not functional of course. :)

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.

> > The debate about drivers failing device removal is an old one, not
> > specific to i2c. My opinion is that .remove() should succeed as much as
> > possible. It should really only fail if the problem is so serious that
> > the system's state would otherwise become a problem (e.g. freeing
> > memory which is still referenced.) This should be a rare case.
> 
> I think that i2c clients devices should be really separated by adapter
> ones, that is we should be free to add and remove any adapter without
> considering the clients state. Then each clients device drivers should
> free each allocated resource they use and the adapters shouldn't know
> about it.

How does your description differ from the current implementation? I
don't follow you.

> Doing like this will semply the code a lot and it allows i2c core to
> be more flexible.

Patches welcome... but I have no clue what you want to do at this point.

-- 
Jean Delvare