1. 11 Jul, 2005 9 commits
    • Jean Delvare's avatar
      [PATCH] I2C: max6875 Kconfig update · 2146fec2
      Jean Delvare authored
      Here is a proposed Kconfig update for the new max6875 i2c chip driver.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2146fec2
    • Jean Delvare's avatar
      [PATCH] I2C: max6875 documentation update · 089bd866
      Jean Delvare authored
      Here is a proposed documentation update for the new max6875 i2c chip
      driver.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      089bd866
    • 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
    • Jean Delvare's avatar
      [PATCH] I2C: Strip trailing whitespace from strings · 541e6a02
      Jean Delvare authored
      Here is a simple patch originally from Denis Vlasenko, which strips a
      useless trailing whitespace from 8 strings in 4 i2c drivers. Please
      apply, thanks.
      
      From: Denis Vlasenko <vda@ilport.com.ua>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      541e6a02
    • david-b@pacbell.net's avatar
      [PATCH] I2C: minor TPS6501x cleanups · 65fc50e5
      david-b@pacbell.net authored
      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: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      65fc50e5
    • Denis Vlasenko's avatar
      [PATCH] I2C: Coding style cleanups to via686a · 6328c0e1
      Denis Vlasenko authored
      On Wednesday 22 June 2005 08:17, Greg KH wrote:
      > [PATCH] I2C: Coding style cleanups to via686a
      >
      > The via686a hardware monitoring driver has infamous coding style at the
      > moment. I'd like to clean up the mess before I start working on other
      > changes to this driver. Is the following patch acceptable? No code
      > change, only coding style (indentation, alignments, trailing white
      > space, a few parentheses and a typo).
      >
      > Signed-off-by: Jean Delvare <khali@linux-fr.org>
      > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
      
      Nice.
      
      You missed some. This one is on top of your patch:
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6328c0e1
    • Linus Torvalds's avatar
    • Linus Torvalds's avatar
    • David S. Miller's avatar
      f7ceba36
  2. 10 Jul, 2005 25 commits
  3. 09 Jul, 2005 6 commits