* 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
Frodo Looijaard