On Mon, May 13, 2013 at 04:14:13PM +0200, Jean Delvare wrote: > 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. > Or use devicetree, which is quite prevalent in embedded systems nowadays. Guenter > > 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
