1. 18 Sep, 2015 1 commit
  2. 04 Oct, 2009 2 commits
  3. 16 Jul, 2008 1 commit
  4. 12 Jul, 2007 1 commit
    • Jean Delvare's avatar
      i2c: Fix the i2c_smbus_read_i2c_block_data() prototype · 4b2643d7
      Jean Delvare authored
      Let the drivers specify how many bytes they want to read with
      i2c_smbus_read_i2c_block_data(). So far, the block count was
      hard-coded to I2C_SMBUS_BLOCK_MAX (32), which did not make much sense.
      Many driver authors complained about this before, and I believe it's
      about time to fix it. Right now, authors have to do technically stupid
      things, such as individual byte reads or full-fledged I2C messaging,
      to work around the problem. We do not want to encourage that.
      I even found that some bus drivers (e.g. i2c-amd8111) already
      implemented I2C block read the "right" way, that is, they didn't
      follow the old, broken standard. The fact that it was never noticed
      before just shows how little i2c_smbus_read_i2c_block_data() was used,
      which isn't that surprising given how broken its prototype was so far.
      There are some obvious compatiblity considerations:
      * This changes the i2c_smbus_read_i2c_block_data() prototype. Users
        outside the kernel tree will notice at compilation time, and will
        have to update their code.
      * User-space has access to i2c_smbus_xfer() directly using i2c-dev, so
        the changed expectations would affect tools such as i2cdump. In order
        to preserve binary compatibility, we give I2C_SMBUS_I2C_BLOCK_DATA
        a new numeric value, and define I2C_SMBUS_I2C_BLOCK_BROKEN with the
        old numeric value. When i2c-dev receives a transaction with the
        old value, it can convert it to the new format on the fly.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
  5. 05 Sep, 2005 2 commits
  6. 11 Jul, 2005 1 commit
  7. 22 Jun, 2005 1 commit