Patch and testing by Rudolf Marek
(mmh) Also added missing declaration for SiS963 support - my bad.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1752 7894878c-1315-0410-8ee3-d5d059ff63e0
makefile. This prevents ever picking up headers from /usr/include
for module builds. Headers must be located in
/lib/modules/`uname -r`/build
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1746 7894878c-1315-0410-8ee3-d5d059ff63e0
From: rysanek@fccps.cz
Dear Chris,
many thanks for writing eeprom.c in the first place.
It has saved me an indefinite amount of time when I needed
to access a 24C02 in a cursed notebook battery pack that
someone's trying to refurbish.
Many more thanks to the authors of lm_sensors and Linux i2c
for writing their software, of course.
I did have to modify eepromer/eeprom.c a bit though, to support
my 24C02. The essential gotcha was this: whereas the 24C16 that
you were using supports maximum burst size of 16 bytes (the same
applies to 24C08 and 24C04), the 24C02 and 24C01 only support
bursts up to 8 bytes long.
I assume that in fact you already know this, as in your code
there's a neat #define called MAX_BYTES to hold exactly this
burst length. And, this was the first thing I modified when
I was trying to solve my problem.
There's one more associated bug though, probably a result of
the fact that your code was not tested with MAX_BYTES values
other than 16. The two for(;;) cycles for reading/writing
consecutive bursts have a wrong terminal condition: they're
comparing the loop count against MAX_BYTES instead of
(BYTES_PER_PAGE/MAX_BYTES).
With this e-mail, I am enclosing the corrected eeprom.c.
My symptoms looked like this: I read the eeprom just fine.
I did my dirty work on two bytes in the eprom dump and
flashed it back. When I re-read the eprom contents,
I found garbage - or so it seemed.
At a closer look, I found out that every second
half-burst (the second 8 bytes of the 16) was correct and
every first 8 bytes was garbled. (Compared that using two
hex editors open on consoles 1 and 2.)
After a few more seconds I found out that the two half-bursts
were really identical.
My final explanation is that each 16byte write resulted in
only the first half-burst being overwritten (the second was
left untouched), only the eeprom latched in all 16 bytes
obediently, so that its FIFO overflew and looped around
exactly once, which resulted in the *second* half-burst
being written into the *first* eight bytes...
Based largely on eeprom.c, I've already hacked a simple util
to write only those two or four bytes that matter to me (the
actual battery capacity and the write-protect stuff).
If the battery refurbishment works out, I'll update my website
to report this success, including all my code snippets.
Thanks again :)
Frank Rysanek
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1743 7894878c-1315-0410-8ee3-d5d059ff63e0
This patch fixes a race condition in the lm85 driver and adds support for the
SMC EMC6D100 and EMC6D101. The EMC6D100 and 101 chips have some additional
features that *are not* currently implemented in the driver, but the chip is
detected (by sensors-detect and the lm85 driver).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1740 7894878c-1315-0410-8ee3-d5d059ff63e0
Christian Hammers <ch@laathspell.de> wrote:
> Hello
>
> I always got the following error when compiling lm_sensors-2.7.0:
>
>
>> gcc -DMODVERSIONS -include /lib/modules/2.4.20-bigvideo-1/build/include/linux/modversions.h -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -fomit-frame-pointer -I. -Ikernel/include -I/usr/local/include -I/lib/modules/2.4.20-bigvideo-1/build/include -O2 -c kernel/busses/i2c-amd8111.c -o kernel/busses/i2c-amd8111.o
>
>
>
>>> kernel/busses/i2c-amd8111.c:26:2: #error Your i2c is too old - i2c-2.7.0 or greater required!
>
>
>
> This is a compile problem as the include files of 2.7.0 are in
> /usr/local/include/linux/. gcc-3.2.3 just puts /usr/local/include at the
> end of the list although it is first on the command line and the info
> page says the list is scanned left to right.
>
>> GNU CPP version 3.2.3 20030316 (Debian prerelease) (cpplib)
>> (i386 Linux/ELF)
>> GNU C version 3.2.3 20030316 (Debian prerelease) (i386-linux)
>> compiled by GNU C version 3.2.3 20030316 (Debian prerelease).
>> ignoring nonexistent directory "/usr/i386-linux/include"
>> ignoring duplicate directory "/usr/local/include"
>> as it is a non-system directory that duplicates a system directory
>> #include "..." search starts here:
>> #include <...> search starts here:
>> .
>> kernel/include
>> /usr/local/include
>> /usr/lib/gcc-lib/i386-linux/3.2.3/include
>> /usr/include
>> /lib/modules/2.4.20-bigvideo-1/build/include
>
>
>
> As a fix I suggest:
>
> # diff -u Makefile.orig Makefile
> --- Makefile.orig 2003-03-19 18:20:38.000000000 +0100
> +++ Makefile 2003-03-19 18:21:08.000000000 +0100
> @@ -178,7 +178,7 @@
> # PROGCPPFLAGS/PROGCFLAGS is to create non-kernel object files (which are linked into executables).
> # ARCPPFLAGS/ARCFLAGS are used to create archive object files (static libraries).
> # LIBCPPFLAGS/LIBCFLAGS are for shared library objects.
> -ALL_CPPFLAGS := -I. -Ikernel/include -I$(I2C_HEADERS) -I$(LINUX_HEADERS)
> +ALL_CPPFLAGS := -I. -Ikernel/include -I$(I2C_HEADERS) -idirafter $(LINUX_HEADERS)
> ALL_CFLAGS := -O2
> ifeq ($(DEBUG),1)
>
>
>
> bye,
>
> -christian-
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1735 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare