1. 16 11月, 2007 2 次提交
    • J
      i2c-dev: Unbound new-style i2c clients aren't busy · bd4217d8
      Jean Delvare 提交于
      Let i2c-dev deal properly with new-style i2c clients. Instead of
      considering them always busy, it needs to check wether a driver is
      bound to them or not.
      
      This is still not completely correct, as the client could become
      busy later, but the same problem already existed before new-style
      clients were introduced. We'll want to fix it someday.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      bd4217d8
    • D
      i2c-dev: "how does it work" comments · 907135aa
      David Brownell 提交于
      This adds some "how does this work" comments to the i2c-dev driver,
      plus separators between the three main components:
      
        - The parallel list of i2c_adapters ("i2c_dev_list"), each of which
          gets a "struct i2c_dev" and a /dev/i2c-X character special file.
      
        - An i2cdev_driver gets adapter add/remove notifications, which are
          used to maintain that list of adapters.
      
        - Special file operations, which let userspace talk either directly to
          the adapter (for i2c_msg operations) or through cached addressing info
          using an anonymous i2c_client (never registered anywhere).
      
      Plus there's the usual module load/unload record keeping.
      
      After making sense of this code, I think that the anonymous i2c_client
      is pretty shady.  But since it's never registered, using this code with
      a system set up for "new style" I2C drivers is no more complicated than
      always using the I2C_SLAVE_FORCE ioctl (instead of I2C_SLAVE).
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      907135aa
  2. 14 10月, 2007 2 次提交
  3. 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
  4. 09 5月, 2007 1 次提交
  5. 13 2月, 2007 1 次提交
  6. 11 12月, 2006 4 次提交
  7. 09 12月, 2006 1 次提交
  8. 02 12月, 2006 1 次提交
  9. 27 9月, 2006 5 次提交
  10. 23 6月, 2006 1 次提交
  11. 06 1月, 2006 5 次提交
  12. 30 10月, 2005 1 次提交
  13. 29 10月, 2005 3 次提交
  14. 06 9月, 2005 1 次提交
  15. 22 6月, 2005 2 次提交
  16. 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