1. 23 4月, 2008 1 次提交
  2. 02 2月, 2008 1 次提交
  3. 12 7月, 2007 2 次提交
    • 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
    • M
      scx200_acb: Use mutex instead of semaphore · 9d9c01ce
      Matthias Kaehlcke 提交于
      The scx200_acb driver use a semaphore as mutex.  Use the mutex API
      instead of the (binary) semaphore.
      Signed-off-by: NMatthias Kaehlcke <matthias.kaehlcke@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Jordan Crouse <jordan.crouse@amd.com>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      9d9c01ce
  4. 09 5月, 2007 1 次提交
  5. 02 5月, 2007 2 次提交
    • J
      scx200_acb: Fix PCI device reference count · 4b4686e7
      Jean Delvare 提交于
      The scx200_acb driver supports two kind of devices, PCI ones and ISA
      ones. Even ISA ones are detected using the presence of a given PCI
      device, and we get a reference to it, but never put it back, so we
      have a leak. Fix it.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      4b4686e7
    • 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
  6. 14 2月, 2007 1 次提交
    • J
      i2c: Declare more i2c_adapter parent devices · 12a917f6
      Jean Delvare 提交于
      Declare the parent device of i2c_adapter devices each time we can
      easily do so. It makes the i2c_adapter appear at the right place in
      the device tree, rather than as a platform device.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Jordan Crouse <jordan.crouse@amd.com>
      Cc: Jody McIntyre <scjody@modernduck.com>
      Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: v4l-dvb-maintainer@linuxtv.org
      Cc: Petr Vandrovec <vandrove@vc.cvut.cz>
      12a917f6
  7. 21 11月, 2006 1 次提交
  8. 27 9月, 2006 1 次提交
  9. 06 8月, 2006 1 次提交
    • D
      [PATCH] SCX200_ACB: eliminate spurious timeout errors · 3e3183ba
      David Woodhouse 提交于
      While busy-waiting for completion, check the hardware after scheduling;
      don't schedule and then immediately check the _timeout_.  If the yield()
      took a long time (as it does on my OLPC prototype board when it's busy),
      we'd report a timeout even though the hardware was now ready.
      
      This fixes it, and also switches the yield() for a cond_resched() because
      we don't actually want to be _that_ nice about it.  I see nice
      tightly-packed SMBus transactions now, rather than waiting for milliseconds
      between successive phases.
      
      Actually, we shouldn't be busy-waiting here at all.  We should be using
      interrupts.  That's an exercise for another day though.
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      Cc: Christer Weinigel <wingel@nano-system.com>
      Cc: <Jordan.Crouse@amd.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3e3183ba
  10. 13 7月, 2006 2 次提交
  11. 23 6月, 2006 2 次提交
  12. 27 5月, 2006 1 次提交
  13. 10 5月, 2006 3 次提交
  14. 24 3月, 2006 7 次提交
  15. 29 10月, 2005 1 次提交
  16. 06 9月, 2005 3 次提交
  17. 22 6月, 2005 1 次提交
  18. 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