1. 02 5月, 2007 3 次提交
    • 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
    • J
      i2c: i2c_adapter devices need no driver · b31366f4
      Jean Delvare 提交于
      Kill i2c_adapter_driver as it doesn't make sense and it prevents
      further i2c-core cleanups. i2c_adapter devices are virtual devices
      (ex-class devices) and as such they don't need a driver.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      b31366f4
    • J
      i2c: Kill i2c_adapter.class_dev · fccb56e4
      Jean Delvare 提交于
      Kill i2c_adapter.class_dev. Instead, set the class of i2c_adapter.dev
      to i2c_adapter_class, so that a symlink will be created for every
      i2c_adapter in /sys/class/i2c-adapter.
      
      The same change must be mirrored to i2c-isa as it duplicates some
      of the i2c-core functionalities.
      
      User-space tools and libraries might need some adjustments. In
      particular, libsensors from lm_sensors 2.10.3 or later is required for
      proper discovery of i2c adapter names after this change.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      fccb56e4
  2. 18 4月, 2007 2 次提交
  3. 23 3月, 2007 2 次提交
  4. 05 3月, 2007 1 次提交
  5. 18 2月, 2007 1 次提交
  6. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  7. 14 2月, 2007 13 次提交
  8. 08 2月, 2007 1 次提交
  9. 06 1月, 2007 1 次提交
    • M
      i2c-mv64xxx: Fix random oops at boot · 3269bb63
      Maxime Bizon 提交于
      I have a Marvell board which has the same i2c hw block than mv64xxx, so
      I'm trying to use i2c-mv64xxx driver.
      
      But I get the following random oops at boot:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000002
      Backtrace: 
      [<c0397e4c>] (mv64xxx_i2c_intr+0x0/0x2b8) from [<c02879c4>] (__do_irq+0x4c/0x8c)
      [<c0287978>] (__do_irq+0x0/0x8c) from [<c0287c0c>] (do_level_IRQ+0x68/0xc0)
       r8 = C0501E08  r7 = 00000005  r6 = C0501E08  r5 = 00000005
       r4 = C048BB78 
      [<c0287ba4>] (do_level_IRQ+0x0/0xc0) from [<c02885f8>] (asm_do_IRQ+0x50/0x134)
       r6 = C0449C78  r5 = F1020000  r4 = FFFFFFFF 
      [<c02885a8>] (asm_do_IRQ+0x0/0x134) from [<c02869c4>] (__irq_svc+0x24/0x100)
       r8 = C1CAC400  r7 = 00000005  r6 = 00000002  r5 = F1020000
       r4 = FFFFFFFF 
      [<c0287efc>] (setup_irq+0x0/0x124) from [<c02880d0>] (request_irq+0xb0/0xd0)
       r7 = C041B2AC  r6 = C0397E4C  r5 = 00000000  r4 = 00000005
      [<c0288020>] (request_irq+0x0/0xd0) from [<c03985f4>] (mv64xxx_i2c_probe+0x148/0x244)
      [<c03984ac>] (mv64xxx_i2c_probe+0x0/0x244) from [<c038bedc>] (platform_drv_probe+0x20/0x24)
      
      
      The oops is caused by a spurious interrupt that occurs when request_irq
      is called. mv64xxx_i2c_fsm() tries to read drv_data->msg, which is NULL.
      
      I noticed that hardware init is done after requesting irq. Thus any
      pending irq from previous hardware usage may cause this.
      
      The following patch fixes it:
      Signed-off-by: NMaxime Bizon <mbizon@freebox.fr>
      Acked-by: NMark A. Greer <mgreer@mvista.com>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      3269bb63
  10. 04 1月, 2007 1 次提交
    • V
      i2c-pnx: Fix interrupt handler, get rid of EARLY config option · 6c566fb7
      Vitaly Wool 提交于
      This fixes two issues raised by David Brownell on the i2c list:
      
      << Someone needs to update i2c-pnx.c to handle the IRQ handler doesn't
      expect pt_regs (gone now for a while), and so it doesn't try to
      reference "mudule_init()" if I2C isn't initialized "early".  For
      that matter, to get rid of that _option_ to initialize then, and
      always init that driver with subsystem_init() ... it's common with
      embedded systems to need I2C access to tweak a GPIO expander or
      do some other work when bringing up drivers, that's not specific
      to USB stacks. >>
      Signed-off-by: NVitaly Wool <vitalywool@gmail.com>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      6c566fb7
  11. 13 12月, 2006 1 次提交
  12. 11 12月, 2006 9 次提交
  13. 08 12月, 2006 1 次提交
    • D
      [ARM] 3995/1: iop13xx: add iop13xx support · 285f5fa7
      Dan Williams 提交于
      The iop348 processor integrates an Xscale (XSC3 512KB L2 Cache) core with a
      Serial Attached SCSI (SAS) controller, multi-ported DDR2 memory
      controller, 3 Application Direct Memory Access (DMA) controllers, a 133Mhz
      PCI-X interface, a x8 PCI-Express interface, and other peripherals to form
      a system-on-a-chip RAID subsystem engine.
      
      The iop342 processor replaces the SAS controller with a second Xscale core
      for dual core embedded applications.
      
      The iop341 processor is the single core version of iop342.
      
      This patch supports the two Intel customer reference platforms iq81340mc
      for external storage and iq81340sc for direct attach (HBA) development.
      
      The developer's manual is available here:
      ftp://download.intel.com/design/iio/docs/31503701.pdf
      
      Changelog:
      * removed virtual addresses from resource definitions
      * cleaned up some unnecessary #include's
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      285f5fa7
  14. 02 12月, 2006 1 次提交
  15. 30 11月, 2006 1 次提交
  16. 24 11月, 2006 1 次提交