1. 12 7月, 2007 1 次提交
    • J
      i2c: Fix the i2c_smbus_read_i2c_block_data() prototype · 4b2643d7
      Jean Delvare 提交于
      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: NJean Delvare <khali@linux-fr.org>
      4b2643d7
  2. 02 5月, 2007 1 次提交
    • D
      i2c: Shrink struct i2c_client · 2096b956
      David Brownell 提交于
      This shrinks the size of "struct i2c_client" by 40 bytes:
      
       - Substantially shrinks the string used to identify the chip type
       - The "flags" don't need to be so big
       - Removes some internal padding
      
      It also adds kerneldoc for that struct, explaining how "name" is really a
      chip type identifier; it's otherwise potentially confusing.
      
      Because the I2C_NAME_SIZE symbol was abused for both i2c_client.name
      and for i2c_adapter.name, this needed to affect i2c_adapter too.  The
      adapters which used that symbol now use the more-obviously-correct
      idiom of taking the size of that field.
      
      JD: Shorten i2c_adapter.name from 50 to 48 bytes while we're here, to
      avoid wasting space in padding.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      2096b956
  3. 14 2月, 2007 2 次提交
  4. 27 9月, 2006 2 次提交
  5. 11 11月, 2005 1 次提交
  6. 08 11月, 2005 1 次提交
    • J
      [PATCH] i2c-viapro: Some adjustments · 8750197f
      Jean Delvare 提交于
      The big i2c-viapro SMBus driver update which went into 2.6.14-git1
      introduced a few minor issues. Nothing critical, but I would like a
      few adjustments to be merged in to fix the following problems:
      
      * VIA should not be spelled Via.
      * Frodo Looijaard and Philip Edelbrock did not write the i2c-viapro
        driver.
      * When debugging is disabled, half of messages would be logged.
      * Drop an unneeded masking.
      * Some port reads can be avoided now that the transaction size is
        passed as a parameter to vt596_transaction().
      * SMBus Receive Byte transactions are used for probing too (for
        EEPROMs), so hide errors on these too.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8750197f
  7. 29 10月, 2005 8 次提交
  8. 06 9月, 2005 2 次提交
  9. 22 6月, 2005 1 次提交
  10. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4