linux.git/drivers/i2c/chips, branch v2.6.13

[PATCH] I2C: 24RF08 corruption prevention (again)

2005-07-29T20:12:51+00:00

The 24RF08 corruption prevention in the eeprom and max6875 drivers wasn't
complete. For one thing, the additional quick write should happen as soon
as possible and unconditionally, while both drivers had error paths before.
For another, when a given chip is forced, the core does not emit a quick
write, so a second quick write would cause the corruption rather than
prevent it.

I plan to move the corruption prevention in the core in the long run, so
that individual drivers don't have to care anymore. But I need to merge
i2c_probe and i2c_detect before I do (work in progress).

Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Linus Torvalds

[PATCH] I2C: ds1337 - fix 12/24 hour mode bug

2005-07-29T20:12:50+00:00

DS1339 manual, page 6, chapter Date and time operation:
  The DS1339 can be run in either 12-hour or 24-hour mode. Bit 6 of the
  hours register is defined as the 12-hour or 24-hour mode-select bit.
  When high, the 12-hour mode is selected.

Patch below makes ds1337 driver work as documented in manual.

Signed-off-by: Ladislav Michl 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Linus Torvalds

[PATCH] I2C: Move hwmon drivers (2/3)

2005-07-11T21:42:50+00:00

Part 2: Move the driver files themselves.

Note that the patch "adds trailing whitespace", because it does move the
files as-is, and some files happen to have trailing whitespace.

From: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

[PATCH] I2C: Move hwmon drivers (1/3)

2005-07-11T21:14:31+00:00

Part 1: Configuration files and Makefiles.

From: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

[PATCH] I2C: SENSORS_ATXP1 must select I2C_SENSOR

2005-07-11T21:10:37+00:00

On Thu, Jun 30, 2005 at 11:47:09PM +0200, Sebastian Pigulak wrote:
> I've tried patching linux-2.6.13-RC1 with patch-2.6.13-rc1-git2 and
> building atxp1(it allows Vcore voltage changing) into the kernel.
> Unfortunately, the kernel compilation stops with:
>
> LD      init/built-in.o
> LD      vmlinux
> drivers/built-in.o(.text+0x92298): In function `atxp1_detect':
> : undefined reference to `i2c_which_vrm'
> drivers/built-in.o(.text+0x921ae): In function `atxp1_attach_adapter':
> : undefined reference to `i2c_detect'
> make: *** [vmlinux] B??d 1
> ==> ERROR: Build Failed.  Aborting...
>
> Could someone have a look at the module and possibly fix it up?

SENSORS_ATXP1 must select I2C_SENSOR.

Signed-off-by: Adrian Bunk 
Signed-off-by: Greg Kroah-Hartman

[PATCH] I2C: drop bogus eeprom comment

2005-07-11T21:10:36+00:00

This simple patch drops an out-of-date comment in the eeprom i2c chip
driver.

Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

[PATCH] I2C: m41t00: fix incorrect kfree

2005-07-11T21:10:36+00:00

Here is a simple path fixing an incorrect kfree in the m41t00 i2c chip
driver. The current code happens to work by accident, but the freed
pointer isn't the one which was allocated in the first place, which
could cause problems later.

Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

[PATCH] I2C: max6875 Kconfig update

2005-07-11T21:10:36+00:00

Here is a proposed Kconfig update for the new max6875 i2c chip driver.

Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

[PATCH] I2C: New max6875 driver may corrupt EEPROMs

2005-07-11T21:10:36+00:00

After a careful code analysis on the new max6875 driver
(drivers/i2c/chips/max6875.c), I have come to the conclusion that this
driver may cause EEPROM corruptions if used on random systems.

The EEPROM part of the MAX6875 chip is accessed using rather uncommon
I2C sequences. What is seen by the MAX6875 as reads can be seen by a
standard EEPROM (24C02) as writes. If you check the detection method
used by the driver, you'll find that the first SMBus command it will
send on the bus is i2c_smbus_write_byte_data(client, 0x80, 0x40). For
the MAX6875 it makes an internal pointer point to a specific offset of
the EEPROM waiting for a subsequent read command, so it's not an actual
data write operation, but for a standard EEPROM, this instead means
writing value 0x40 to offset 0x80. Blame Philips and Intel for the
obscure protocol.

Since the MAX6875 and the standard, common 24C02 EEPROMs share two I2C
addresses (0x50 and 0x52), loading the max6875 driver on a system with
standard EEPROMs at either address will trigger a write on these
EEPROMs, which will lead to their corruption if they happen not to be
write protected. This kind of EEPROMs can be found on memory modules
(SPD), ethernet adapters (MAC address), laptops (proprietary data) and
displays (EDID/DDC). Most of these are hopefully write-protected, but
not all of them.

For this reason, I would recommend that the max6875 driver be
neutralized, in a way that nobody can corrupt his/her EEPROMs by just
loading the driver. This means either deleting the driver completely, or
not listing any default address for it. I'd like this to be done before
2.6.13-rc1 is released.

Additionally, the max6875 driver lacks the 24RF08 corruption preventer
present in the eeprom driver, which means that loading this driver in a
system with such a chip would corrupt it as well.

Here is a proposed quick patch addressing the issue, although I wouldn't
mind a complete removal if it makes everyone feel safer. I think Ben
has plans to replace this driver by a much simplified one anyway.

Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

[PATCH] I2C: minor TPS6501x cleanups

2005-07-11T21:10:36+00:00

This includes various small cleanups and fixes to the TPS 6501x driver that
came mostly from review feedback by Jean Delvare; thanks Jean!  Also some
goofy whitespace gets fixed.

Signed-off-by: David Brownell 
Signed-off-by: Greg Kroah-Hartman