* The i2c package can no longer be compiled as part of the lm_sensors tree
* The archive of the i2c package is removed
* smbus, i2c-dev and i2c-proc modules and headers have been removed; they
are now completely integrated into the i2c package
* The fake i2c.h header has been removed; this also allowed us to remove
the ugly LM_SENSORS and TBD defines.
* A new variable I2C_HEADERS is introduced in the Makefile. This allows
us to install the i2c headers in, for example, /usr/local/include/linux.
* All files now include <linux/i2c.h> instead of "i2c.h" and "smbus.h"
Status: 'make dep' works, all the right include files are found. 'make all'
does not yet work.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@496 7894878c-1315-0410-8ee3-d5d059ff63e0
gl518sm module
Besides the usual parameters, eeprom.o understands insmod parameter 'checksum'.
Set it to one (ie. 'modprobe eeprom checksum=1') to make it ignore any
chips which do not come through the checksum.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@371 7894878c-1315-0410-8ee3-d5d059ff63e0
device drivers. Specifically, I added these lines:
(in includes list)
#include "i2c-isa.h"
(Near beginning of *-attach-adapter function)
/* Make sure we aren't probing the ISA bus!! */
if (i2c_is_isa_adapter(adapter)) return 0;
This may be redundant is a couple of the files, but it shouldn't hurt.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@283 7894878c-1315-0410-8ee3-d5d059ff63e0
All our own code (ie. anything not in the i2c directory) compiles now without
warnings, even with WARN=1 (which sets -Wall -Wstrict-prototypes -Wshadow
-Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wnested-externs
-Winline). There is one exception: the lex code (conf-lex.l) complains about
unused functions. That's flex' fault, not ours!
The i2c code still emits many warnings with the above flags; that's Simon's
problem.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@233 7894878c-1315-0410-8ee3-d5d059ff63e0
* Only first 64 bytes are read (enough for SDRAM EEPROM data) in 16 byte
blocks (separate proc files).
* No writing to EEPROMs. It's actually quite easy to add support for
writing, but I was being very paranoid about killing my DIMMs. I may add
write support, but make it only available when a #define is specified.
Now for a user app to decode the values...
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@71 7894878c-1315-0410-8ee3-d5d059ff63e0
driver (used as a template). It is completely non-functional at this
point, but it's a start. There is a lot of code still specific to the
lm75 in it, so don't try to use it yet. ;') Also note that there needs
to be some concern with using it because a 'write' and a 'read' to an
EEPROM on the SMBus are very similar. So, we need to be carefull not
to start crippling SDRAM DIMMs due to unfinished/buggy code.
This should (when working) be able to read EEPROMs:
* In SDRAM DIMMs which specify the type, clocking, etc. of the DIMM.
* the EEPROMs in the new Intel Xeon processors.
* Any other EEPROM connected to the SMBus conforming to the standard
SMBus comminucation methods for SMBus EEPROMs.
Since only eight possible addresses are available for EEPROMs (at
least from the spec I'm looking at from Atmel), the code will
only probe for eight. Notice that this can lead to some problems
for machines for which this is true: # of SDRAM DIMMs + # of Xeons > 8
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@45 7894878c-1315-0410-8ee3-d5d059ff63e0
Kyosti Malkki