• Jean Delvare's avatar
    [PATCH] I2C: New max6875 driver may corrupt EEPROMs · 9ab1ee2a
    Jean Delvare authored
    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: default avatarJean Delvare <khali@linux-fr.org>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    9ab1ee2a
max6875.c 13.7 KB