On Mon, 13 May 2013 09:54:47 -0400, Jean-François Dagenais wrote: > Salut Jean, merci de participer! > > On 2013-05-13, at 4:11 AM, Jean Delvare wrote: > > > > > Guenter is right. You never have to disable auto-detection in the slave > > drivers (jc42 etc.) All these slave drivers do is claim "I _can_ do > > auto-detection", not "I _will_ do auto-detection." It's always up to the > > I2C adapter driver, whether auto-detection will happen or not. And it > > is disabled by default. So if you don't want it, just do not enable it > > in the bus driver. You can even set it per adapter, when the driver > > controls more than one adapter, and per bus segment, when multiplexing > > is taking place. > > I am just wondering where the clean hook is for doing this. From what I can > gather, the master driver(s I've seen) declare ".class = I2C_CLASS_HWMON | > I2C_CLASS_SPD," pretty statically. Is it just that they are missing this > flexibility? Something along the lines of patching the pdata of such a master > driver to provide a 'class' variable in pdata? Yes, exactly. > If so, one would have to take > into account the existing users of the master which expect the previous class > setting which may not be '0', thus requiring patching the existing upstreamed > users... Suggestions? Yes, you have to do something like that. The static class declarations come from the PC world drivers where they (almost) never change. Embedded systems definitely want a per-bus decision and should avoid static declarations as much as possible. Especially when in most cases they know exactly what slaves they are so they don't need auto-detection. There's a reason why auto-detection is an optional feature... -- Jean Delvare -- 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
