sensors-detect detection is now complete; I think nothing else needs
to be done in the tree?!? (except documentation of course)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@643 7894878c-1315-0410-8ee3-d5d059ff63e0
It now warns you about built-in drivers, and should always work. It will
still give a too long list of modules if some things are built into the
kernel. There is no real solution to this; the best thing to do would
probably be to ask the user where the kernel tree is located, and use
.config to determine what is built into the kernel. But not everybody
has such a kernel tree - especially once we get to the point where
people will distribute binary versions.
I also updated the list of undetectable adapter.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@589 7894878c-1315-0410-8ee3-d5d059ff63e0
Changed adm9240 confidence from 8 to 7 to let adm1022 win,
not sure about register 0x3F in adm1022.
Removed 0x69 from i2c range on all drivers, that address
looks entrenched for clock chips.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@540 7894878c-1315-0410-8ee3-d5d059ff63e0
* removed algorithm registration in i2c-isa
* renamed i2c-via2.o to i2c-viapro.o in the driver messages
* added detection for new drivers in sensors-detect script
* minor gl518sm fix
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@522 7894878c-1315-0410-8ee3-d5d059ff63e0
This one was easy. A MAX1617 is just a MAX1617A with better detection.
Life is beautiful!
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@375 7894878c-1315-0410-8ee3-d5d059ff63e0
Detection is completely impossible, but sensors-detect now assumes with a
confidence of 1 (the lowest possible) that any chip in the LTC1710 address
range is a real LTC1710. Perhaps I should remove this again, as I don't
think this chip will be encountered 'in the wild' if your name is not Phil -
in which case you would have soldered it to your SMBus yourself, so you
should know what you are doing...
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@372 7894878c-1315-0410-8ee3-d5d059ff63e0
Also fixed a small lm78 problem and synchronised the detect script with
the Winbond detection.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@341 7894878c-1315-0410-8ee3-d5d059ff63e0
The detection program can now be told that it should probe for more
addresses than the kernel driver module; it automatically generates
the necessary insmod parameters for the module if chips are found on
these non-standard addresses. Very useful for the LM78, for instance;
the driver still only check 0x20-0x2f, but the probe program checks
all addresses.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@336 7894878c-1315-0410-8ee3-d5d059ff63e0
Supported insmod parameters:
ignore, ignore_range
probe, probe_range
force, force_lm78, force_lm78j, force_lm79
force* overrules ignore* overrules probe*
The *_range parameters need three elements for each specification:
bus,start_addr,end_addr
The address ranges are inclusive.
The other parameters need two elements for each specification:
bus,addr
In each case, '-1' stands for 'any I2C bus', and 9191 stands for
'the ISA bus' (Bonus question: who can figure out why I choose 9191?)
In each case, just append if you want several specification, for example:
insmod lm78 probe=9191,0x2a0,1,0x56
force_* does no detection, not even chip detection; it blindly assumes
you know what you are doing. plain force does the chip detection, but
nothing else; but it can still fail if the register read-out does not
match a chip type.
Detection is done in exactly the same way as sensors-detect, except that
only the range 0x20-0x2f is examined by default. This needs to be
synchronized somehow with the detect script. I would rather scan the whole
I2C address range, but with those clueless PIIX4 hangs when clock chips
are read, that would simply give too much trouble.
The detect script has slightly better ISA detection now, too.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@325 7894878c-1315-0410-8ee3-d5d059ff63e0
* Either Phil had not done a 'cvs update', or I forgot a 'cvs commit'; anyway,
the last changes to detect.pl have been ported to sensors-detect.
* Added a rule to the Makefile fragment to install it in $(SBINDIR).
* Added SBINDIR to the main Makefile.
* Deleted detect.pl
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@323 7894878c-1315-0410-8ee3-d5d059ff63e0
* No more redefined complaints of MODULE_* symbols for 2.0 kernels
This was introduced by the last archive of Simon
* Correct load order of adapters in detect script modprobe report
You can't assume things come out of a hash in the same order as you
put them in, of course :-(
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@303 7894878c-1315-0410-8ee3-d5d059ff63e0
detection bug
The lesson of today: the control variable in foreach loops is local to the
loop and regains his former value on exit of the loop. Oops.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@298 7894878c-1315-0410-8ee3-d5d059ff63e0
* Redid the internal report structure
* Separated the report function from main
* Rewrote the structure insertion functions
All in all, the functions have become much more readable and maintainable.
The downside: there are almost certainly new bugs created.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@281 7894878c-1315-0410-8ee3-d5d059ff63e0
