From Brendan Heading:
You may be aware of the musl C-library implementation, which tries to
be strictly standards compliant, avoids non-standard extensions, etc.
Some distributions have adopted it as their standard C library, in
others (such as buildroot) it is a configuration alternative.
Vanilla lm-sensors does not compile under musl, due to the following
excerpt which appears in four different places. The code is checking
that the glibc version is greater than 2.0.
#if defined(__GLIBC__) && __GLIBC__ == 2 && __GLIBC_MINOR__ >= 0
#include <sys/io.h>
#else
#include <asm/io.h>
#endif
This fails under musl does not define __GLIBC__ (in fact, by design,
it doesn't provide any way to identify itself at all) - which causes
it to try to include <asm/io.h> rather than <sys/io.h>.
It's a long time since glibc 2.0.1 was released - 1997. Accordingly,
it seems to make little sense at this stage to try to retain
compatibility with very old libcs - so maybe it should be removed
entirely.
Sometimes the hardware expects 16-bit or 32-bit writes rather than byte
writes. Add support to isaset so that the user can ask for such writes.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@5962 7894878c-1315-0410-8ee3-d5d059ff63e0
Sometimes the hardware expects 16-bit or 32-bit reads rather than byte
reads. Add support to isadump so that the user can ask for such reads.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@5961 7894878c-1315-0410-8ee3-d5d059ff63e0
be available in Linux kernel 2.6.23. Binary compatibility is guaranteed,
source code compatibility isn't, but the incompatibility will be
spotted quickly as the prototype of the helper function
i2c_smbus_read_i2c_block_data() changed. The only problem would be if
a program is calling i2c_smbus_access() directly. Hopefully this should
be a rare case. The py-smbus binding code is in this case and will be
adjusted soon.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4419 7894878c-1315-0410-8ee3-d5d059ff63e0
back from the address port, so the value 0xff is returned, causing
a false positive with the original test. Testing explicitly for 0x80
instead of only testing that bit 7 is set, works around it.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4406 7894878c-1315-0410-8ee3-d5d059ff63e0
does, but it only triggers a transaction on even register addresses,
relying on the target chip to increment its internal register pointer
between the high and low byte of the word. EEPROMs behave that way, so
this mode makes it possible to dump an EEPROM contents faster. I2C Block
Read is still faster but it isn't available on all busses, while SMBus
Read Word is very popular. This mode also makes it possible to test
SMBus Read Word transactions on a given adapter using common EEPROMs.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@3286 7894878c-1315-0410-8ee3-d5d059ff63e0
Discard I2C_FUNC_SMBUS_*_PEC defines. i2c clients are not supposed to
check for PEC support of i2c bus drivers on individual SMBus
transactions, and i2c bus drivers are not supposed to advertise them.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@3176 7894878c-1315-0410-8ee3-d5d059ff63e0
Only use PEC on the register write, not the readback, as it has proven to
cause trouble on some chips. Reads with PEC can be tested using i2cget.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@3109 7894878c-1315-0410-8ee3-d5d059ff63e0
chip. It has byte data and word data read support as well as byte
write/byte read, and supports PEC too. Beware that byte write with PEC
enabled can write random values to registers on non-PEC-aware chips.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@3108 7894878c-1315-0410-8ee3-d5d059ff63e0
is requested. Print the correct bus type if bus functionality can be
queried (will work if i2c-dev is loaded and user has write access to
/dev/i2c*).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@3078 7894878c-1315-0410-8ee3-d5d059ff63e0
