On Thu, 17 Nov 2005 14:20:04 +0100 (CET) "Jean Delvare" <khali at linux-fr.org> wrote: > I think you should just forget about ->command. It's there for > historical reasons, but all in all doesn't make much sense that I can > see. It's kind of a bold statement at this point, but I think ->command > is likely to be removed in the future. I would need to spend more time > investigating the exact implementation and uses of it before going on > about this though, and such extra time I unfortunately don't have right > now. I can tell you about the two kind of uses I've seen until now: a) media drivers use it to send ioctls. b) other drivers (rtcs) use it to send non-ioctl messages. If an "other driver" receives an ioctl via i2c_clients_commands an oops is likely to happen. If you don't give the media drivers a way to send ioctl-like commands to theri chips, they will star exporting tons of function.. I agree that you can't stop the caos in the universe, but that is like throwing an atomic bomb in the middle of the caos... > > Do we agree here? > > Probably not. My views are more like: > > * The platform code needs x1205, so it loads it if needed. > Platform-specific data can be used to hint x1205 on what adapter, > address pair it should attach to. I agree. > * When loaded, x1205 registers with i2c-core (as it already does) and > rtc-core or whatever this will be called. If it registers with "rtc-core", you will be forced to use it as rtc, right? Otherwise I should have an option array which specifies which instance of the client should register and which not, because I may have two rtcs (ipotetically) connected. That's doable, but I would rather preferred to have only the portion of the driver that is strictly relevant to the I2C in i2c/chips. That would also mean tha more code will be repeated across different rtc drivers, code that will be the 95% the same, maybe except for function names. > But I probably better stop here, as I am not the one who will write that > code, at least not within the next few months. Most of the problem > really doesn't depend on i2c, so I will happily leave the discussion > and decision to others. Just let me know who will have to decide :) I need to address this situation in the near future. If someone decides, I will be happy to write code _according_ to the decision. If nobody decides, nothing will change. -- Best regards, Alessandro Zummo, Tower Technologies - Turin, Italy http://www.towertech.it
