Re: [lm-sensors] i2c multimaster and the device driver detect function

[Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>]

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
>