i2c_force_data

Jean Delvare khali at linux-fr.org
Thu Nov 11 08:39:17 CET 2004


Hi Greg,

> You can now add pci ids on the fly through sysfs, which causes drivers
> to accept new devices from what they were originally compiled with.
> 
> We're extending that logic to say, "try to bind this driver to that
> device" from userspace through sysfs, which should be sufficient to
> replace this force logic, right?

So basically we would load the driver first, it wouldn't recognize the
device at first, then we would write something to sysfs and the driver
would attempt to recognize the device again, successfully this time?

This matches the "force" module parameter we have pretty well. However
we also have e.g. force_w83782d, force_lm84 etc... which not only
forcibly bind a driver to a device, but also invite the driver to handle
that chip in a specific way. Will this be doable as well?

> > I'm more concerned about bus load. We have seen poor hardware
> > implementations and messy BIOSes causing SMBus locks on high load.
> > We don't want this to happen at boot time.
> 
> Hm, I'll have to think about this.  I really don't want a white/black
> list of busses that this will work on, as if you look at the kernel
> code today, we already scan all addresses for validity in i2c_detect()
> before handing off to the chip driver (yeah, that's a bit different
> from scanning all addresses, I agree, but conceptually it's the same.)

That's not quite what I was thinking about. My point was that
sensors-detect will issue dozens of register reads for each responsive
address, including several reads on the very same registers. This is
caused by a faulty design in the first place (well the script knew about
half a dozen client chips in the first place, and 85 now, that explains
it). For a family of chip we would need one detection function that
tells what the most likely chip of the family is. Instead we have one
function per chip type returning its own confidence value (zero for
almost all and non-zero for one or sometimes two). Each function is
probing the registers again, thus the bus load. This could be improved
by introducing a local cache of the registers, but this ain't trivial
either because some chips have "banks" which means that a given address
may be a different register next time you ask for it. Rewriting the
whole thing with a better design would probably be even better, but
sensors-detect is a very sensible piece of code and it simply seems that
nobody wants to take the risk.

The client drivers, in that respect, behave much better than
sensors-detect does.

The bus load issue in sensors-detect wasn't critical as long as it was a
stand-alone script meant to be run just once. Now that a similar action
is supposed to be taken on each boot (or bus driver load) this is a
different matter.

My proposal would be not to blacklist any bus, but to limit the bus
traffic we will be generating. One way to do that is to only support
autoloading of the easy-to-identify chips through the hotplug interface.
Recent chips have chip ID and manufacturer ID registers at relatively
standard locations. These can be easily identified. Older chips cannot
and we use bus-intensive, half-reliable heuristics to detect them. See
the CVS log of sensors-detect if you want to figure out how much I have
been refining detection heuristics in the last year. Maybe we don't want
to support such chips through hotplug.

> Wonder if we just sleep for a second or two between bus address
> probes, if that will help out or not :)

You must be kidding, right?

Thanks.

-- 
Jean Delvare
http://khali.linux-fr.org/



More information about the lm-sensors mailing list