khali at linux-fr.org
Wed Feb 2 14:42:41 CET 2005
Hi Mark & all,
> > I don't see the point in having a kernel driver for this. The driver
> > currently exposes all the registers directly to procfs, with arbitrary
> > names. You could achieve the same goal with a user-space program relying
> > on i2c-dev. I guess that this device is meant for a very specific use
> > anyway.
> well you have a point there, but that comment also applies to pcf8574, for
I completely agree, and some other drivers as well. I believe that the
different devices have been handled too similarly for a long time now.
The i2c core is one thing, i2c/smbus master drivers are another, sensor
chips another, misc chips yet another, and user-space tools as well. One
may wonder why bus drivers do belong to the lm_sensors package and not
to i2c package. Likewise, some chip drivers are part of lm_sensors for
historical reasons but don't truly belong there. The fact that
libsensors and sensors know about a number of non-sensors chips doesn't
make much sense when you think of it. And the fact that the 2.4 kernel
drivers, libsensors and sensors are so tight together is much of a
The reason why I mention all that now is that we will inevitably have to
make things way clearer on the 2.6 kernel side within a short time.
Hardware monitoring chips must be conceptually separated from the i2c
subsystem, because so many of them are now completely unrelated with
that. i2c-isa will soon be history, or so I hope. Also, the 2.6-only
implementation of libsensors (someday...) will only handle sensor chips,
based on the well-defined standard interface, no more chip-specific
stuff. While we are still far from this, it would be great to walk in
the right direction already.
> I think this driver has potential for enhancement...
> for example, if it's really used as a fan controller, the files could be
> renamed as pwmx and then it would work with pwmconfig, etc.
> So IMHO it was worth keeping.
Agreed, the chip can be used as a fan controller and that would belong to
the project in this case. But who is using this chip and driver exactly?
I still would like to know where the chip was seen.
At any rate, I would prefer a driver that specifically handles fan
control and only that, with standard interface, and a user-space tool
which handles the chip as an I/O expander, and only does that. I doubt
that the chip would be used for both at once, would it?
Side note about the chip detection (or lack thereof):
You said that the chip was impossible to detect. I don't think so.
During the past few years, we learnt quite a few tricks for detecting
chips, which would certainly apply here.
First, I see unused bits in the configuration register and fan speed
register. Should probably always read 0.
Then, as for most low register count chips, we could check what happens
when you read past the last register. Sometimes it returns 0, sometimes
the last read value, sometimes an i2c error. Sometimes registers cycle
over some boundary (like the LM75 does). All this can be used to improve
the detection - even if real identification registers are still prefered
for speed and reliability, of course. May we see a dump of a mic74 chip?
More information about the lm-sensors