Add all relevant information to the CHANGES file. Fix the leading case
of some entries for consistency, and remove one which wasn't worth
mentioning.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Add the current maintainer to the mailing list as the contact points
for bug reports. This ensure that the reports will be read by the
right person.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
While the laptop I originally developed decode-vaio on, only had 5 i2c
buses, there could be more on other models, and there are definitely
more on the system I use to test the script (using i2c-stub) these
days. So look for the VAIO EEPROM on up to 32 i2c buses to be on the
safe side.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
There used to be only 1 eeprom driver (named "eeprom") but now
there are 3 and the legacy "eeprom" driver is not the preferred
option. So list all 3 drivers in our documentation to prevent
confusion.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Wolfram Sang <wsa@kernel.org>
Short writes used "daddress" for the value, but the masking code did
not expect that, and instead applied the mask to a variable that was
never used.
So change short writes to use "value" for the value, as all other
commands do. Adjust all code paths accordingly.
Reported by David Jedynak.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Emit a warning if the bus master driver in the kernel did not set the
message length correctly with I2C_M_RECV_LEN. This can be determined
from the returned value in the buffer.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Update the list of memory vendors as of June 2020, including 14
renames.
I also added a runtime sanity check on the number of vendors per
page, as it is very easy to get it wrong.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
For all manpages installed on my Debian system, add a BUGS section, so
people can easily find whom to contact.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Sometimes I need to add some flags (like -static for the linker), so
allow this for all CFLAGS and LDFLAGS used in this project.
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Acked-by: Jean Delvare <jdelvare@suse.de>
Make the parser more flexible so as to recognize the dump files
generated by "hexdump -C" as a valid input.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
The header comment only mentioned the legacy eeprom driver, while the
at24 and ee1004 drivers should be used nowadays.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
We moved away from Subversion long ago, so $Revision$ and $Date$ are
no longer being resolved. Just use the version of i2c-tools itself.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
No information available yet about the contents of the DDR5 SPD
EEPROMs but we can already report the basic memory type.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Because it is DDR memory, transaction rate is twice the actual clock
speed. What the user is interested in is MT/s, and that's the number
we display, so use the right unit.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
When not reading from dump files, print which kernel driver is being
used. This will help spot setup mistakes where the legacy eeprom
driver stole EEPROMs from the ee1004 driver for DDR4 memory.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
If using the wrong driver, or if reading from a truncated dump file,
make sure we don't attempt to use data bytes beyond what is
available. Doing so would spit pages of cryptic warnings to the user,
explicit error messages are much better.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
The cycle time of high-speed memory modules is stored rounded. We
already have a heuristic to un-round it and display the expected
speed for DDR3 modules. Use the same heuristic for DDR4.
For example this will make PC4-17000 memory properly displayed as
operating at 2133 MHz instead of 2132 MHz. As a side effect, this
fixes a bug where the maximum speed wouldn't be listed in section
"Timings at Standard Speeds" if it had been computed incorrectly
due to the rounded cycle time.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
The I2C standard reserves addresses 0x03-0x07. Adapt our tools to that.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The text describing the address to be used did not reflect the recent
change where some of the functionality of '-f' has been seperated into
'-a'.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
There was a last instance of sprintf which somehow was not converted.
I know it can't fail, but for consistency, let's use snprintf and
check for truncation as we already do in gather_i2c_busses().
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Add all the JEDEC-registered manufacturer names added since JEP106AQ.
Signed-off-by: Vincent Palatin <vpalatin@upmem.com>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
The Python bindings haven't been updated after commit
330bba29f3 ("libi2c: Properly
propagate real error codes on read errors"). This led to erronenous
behavior every time an error other than -1 is returned by i2c_smbus_*
functions.
[JD: Edited description.]
Signed-off-by: Georgii Staroselskii <georgii.staroselskii@emlid.com>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Allow the user to define the installation prefix as an alternative
to "/usr/local".
Suggested by Per Olav Kroka.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Allow the user select a different strip tool for the build
(same as done with the CC and AR variables).
Contributed by Per Olav Kroka.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
The libi2c library is released under the LGPL, not GPL, as explained
in the README file and documented in lib/Module.mk. Thanks to
Aurelien Jarno for pointing out the inconsistency.
A little bit of history:
The code started its life two decades ago as part of the lm-sensors
project, which was released as a whole under the GPL originally,
including the library part (libsensors).
In 2007, I decided to split the i2c tools, which are not specific
to sensor devices, to a separate package.
In 2009, as I was working on lm-sensors v3, I contacted all the
original authors to get their approval to release the upcoming and all
future versions of libsensors as LGPL instead, to allow wider
adoption. The proposal was accepted by all original authors.
In 2012, I decided to turn the inlined i2c_smbus_* helper functions
into a proper library, with the intent to release it under the LGPL,
as is the common practice for libraries. As the authors of this code
is a subset of the authors of libsensors, I assumed their agreement
for libsensors could be extended to libi2c as well. This is the
reason why LGPL is mentioned in README and lib/Module.mk.
Unfortunately, when working on the library code itself, I forgot to
update the comments in the source files. Let's fix them now.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
We now have the flag '-a' for all i2c-tools to allow access for all
addresses. This was tied in i2ctransfer to the '-f' flag. Remove it and
keep that feature to '-a' only. This is also more in sync with the other
i2c-tools which use '-f' only to access already busy devices.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Reviewed-by: Peter Rosin <peda@axentia.se>
If the user is sure that the reserved 0x00 - 0x02 and 0x77 - 0x7f ranges
are not needed by its devices, then the "-a" option can be passed for
allowing all theorical addresses to be used. It is then possible to
access devices in this address range.
Signed-off-by: Romain Porte <romain.porte@nokia.com>
Reviewed-by: Peter Rosin <peda@axentia.se>
[wsa: imonr fixes to commit message]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The <linux/i2c-dev.h> header file is provided by the kernel, so drop
our own copy of this file.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Do not attempt to install the dynamic library when build of that library
is disabled. Fixes the following installation error:
install -m 755 lib/libi2c.so.0.1.0 .../target/usr/lib
install: cannot stat 'lib/libi2c.so.0.1.0': No such file or directory
lib/Module.mk:90: recipe for target 'install-lib' failed
Cc: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Fixes: 9906b2ecb6 ("Makefile: Add flag to disable dynamic library")
Absence of this dependency caused parallel build to run into a race
and break.
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
If the user disables the build of the dynamic library, we have to
link the tools with the static library. If we don't, the dependencies
will cause the dynamic library to be built regardless of the user's
request.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Fixes: 9906b2ecb6 ("Makefile: Add flag to disable dynamic library")
LIB_LINKS should be added as a dependency only when
BUILD_DYNAMIC_LIB is enabled.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Fixes: 9906b2ecb6 ("Makefile: Add flag to disable dynamic library"
Jean Delvare
Wolfram Sang
Wolfram Sang
Francois Cartegnie
Joakim Tjernlund
Vincent Palatin
Georgii Staroselskii
Wolfram Sang
Romain Porte
Baruch Siach
Maxin B. John
Angelo Compagnucci