On Fri, Feb 06, 2009 at 10:15:19PM +0100, Jean Delvare wrote: > > 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. Ok. > > > 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. 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? > > > 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. 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. > > 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. 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. Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@xxxxxxxxxxxx Linux Device Driver giometti@xxxxxxxx Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
