1. 22 11月, 2010 1 次提交
  2. 25 10月, 2010 1 次提交
    • J
      i2c: Fix Kconfig dependencies · 0a57274e
      Jean Delvare 提交于
      drivers/i2c/algos/Kconfig makes all the algorithms dependent on
      !I2C_HELPER_AUTO, which triggers a Kconfig warning about broken
      dependencies when some driver selects one of the algorithms. Ideally
      we would make only the prompts dependent on !I2C_HELPER_AUTO, however
      Kconfig doesn't currently support that. So we have to redefine the
      symbols separately for the I2C_HELPER_AUTO=y case.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NMichal Marek <mmarek@suse.cz>
      0a57274e
  3. 12 8月, 2010 2 次提交
  4. 14 3月, 2010 2 次提交
  5. 02 3月, 2010 1 次提交
    • J
      i2c: Separate Kconfig option for i2c-smbus · e2ca3074
      Jean Delvare 提交于
      Having a separate Kconfig option for i2c-smbus makes it possible to
      build that support as a module even when i2c-core itself is built-in.
      Bus drivers which implement SMBus alert should select this option, so
      in most cases this option is hidden and the user doesn't have to care
      about it.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Trent Piepho <tpiepho@freescale.com>
      e2ca3074
  6. 07 12月, 2009 1 次提交
  7. 19 9月, 2009 1 次提交
  8. 11 8月, 2008 1 次提交
  9. 10 5月, 2007 1 次提交
  10. 02 5月, 2007 2 次提交
    • J
      Use menuconfig objects - I2C · 16538e6b
      Jan Engelhardt 提交于
      Allow the whole I2C menu to be disabled at once without diving into
      the submenus for deselecting all options (should the user desire so).
      Signed-off-by: NJan Engelhardt <jengelh@gmx.de>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      16538e6b
    • D
      i2c: Add i2c_board_info and i2c_new_device() · 9c1600ed
      David Brownell 提交于
      This provides partial support for new-style I2C driver binding.  It builds
      on "struct i2c_board_info" declarations that identify I2C devices on a given
      board.  This is needed on systems with I2C devices that can't be fully probed
      and/or autoconfigured, such as many embedded Linux configurations where the
      way a given I2C device is wired may affect how it must be used.
      
      There are two models for declaring such devices:
      
       * LATE -- using a public function i2c_new_device().  This lets modules
         declare I2C devices found *AFTER* a given I2C adapter becomes available.
         
         For example, a PCI card could create adapters giving access to utility
         chips on that card, and this would be used to associate those chips with
         those adapters.
      
       * EARLY -- from arch_initcall() level code, using a non-exported function
         i2c_register_board_info().  This copies the declarations *BEFORE* such
         an i2c_adapter becomes available, arranging that i2c_new_device() will
         be called later when i2c-core registers the relevant i2c_adapter.
      
         For example, arch/.../.../board-*.c files would declare the I2C devices
         along with their platform data, and I2C devices would behave much like
         PNPACPI devices.  (That is, both enumerate from board-specific tables.)
      
      To match the exported i2c_new_device(), the previously-private function
      i2c_unregister_device() is now exported.
      
      Pending later patches using these new APIs, this is effectively a NOP.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      9c1600ed
  11. 27 9月, 2006 1 次提交
  12. 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