On Thu, Feb 05, 2009 at 04:02:43PM -0800, David Brownell wrote: > On Thursday 05 February 2009, Rodolfo Giometti wrote: > > > > When we are removing an adapter we decide to ignore any active client > > detaching faults for two reasons: > > > > 1) one (or more) active client may be switched off, so it cannot > > replay to the "adapter removed" event. > > > > 2) it shouldn't happen, and even if it happens it may be due a bus > > fault which can be resolved by resetting the adapter (most of them > > can be resetted simply by rmmod and then insmod the module again). > > This bothers me. If the client can't detach, it can't; > there may be all kinds of chaos introduced by trying > to fake success in such cases. Like resources that > suddenly just vanish, leaving breakage in their wake. > > If this is a shutdown() path, where it's basically > just a polite driver notification, that's one thing. > > But I2C gets used as a system control bus, so this > sort of "ignore the errors" stuff worries me a lot.
If so I suppose we should take in account the adapter->client_unregister() return value also, which is currently ignored in i2c_unregister_device() function... However, since I2c is a bus it could be possible that a slave device stops functioning (or the user decides to turn it off), so aborting the adapter removal in these cases can be not right... moreover if the adapter should be logically separated from the i2c clients I suppose is better allowing the user to remove (and eventually replace) it and then resolving i2c client's stale states into the relative driver. I suppose this is the same behaviour of USB bus: we can remove an USB host adapter independently from USB devices. Ciao, Rodolfo -- gnu/Linux Solutions e-mail: [email protected] Linux Device Driver [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
