1. 10 3月, 2007 2 次提交
  2. 24 2月, 2007 2 次提交
  3. 18 2月, 2007 1 次提交
  4. 17 2月, 2007 5 次提交
  5. 16 2月, 2007 1 次提交
  6. 15 2月, 2007 2 次提交
    • T
      [PATCH] Scheduled removal of SA_xxx interrupt flags fixups · 38515e90
      Thomas Gleixner 提交于
      The obsolete SA_xxx interrupt flags have been used despite the scheduled
      removal.  Fixup the remaining users.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: Wim Van Sebroeck <wim@iguana.be>
      Cc: Roland Dreier <rolandd@cisco.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: James Simmons <jsimmons@infradead.org>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      38515e90
    • 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. 12 2月, 2007 1 次提交
  8. 10 2月, 2007 2 次提交
  9. 08 2月, 2007 19 次提交
  10. 23 1月, 2007 1 次提交
  11. 06 1月, 2007 2 次提交
  12. 21 12月, 2006 2 次提交
    • T
      USB: u132-hcd/ftdi-elan: add support for Option GT 3G Quad card · 4b87361d
      Tony Olech 提交于
      ELAN's U132 is a USB to CardBus OHCI controller adapter,
          designed specifically for CardBus 3G data cards to
          function in machines without a CardBus slot.
      The "ftdi-elan" module is a USB client driver, that detects
          a supported CardBus OHCI controller plugged into the
          U132 adapter and thereafter provides the conduit for
          for access by the "u132-hcd" module.
      The "u132-hcd" module is a (cut-down OHCI) host controller
          that supports a single OHCI function of the CardBus 
          card inserted into the U132 adapter.
      
      The problem with the initial implementation is that when
      the CardBus card inserted into the U132 adapter has multiple
      functions (and a CardBus card can support up to 4 functions),
      it was the first function that was arbitrarily choosen.
      
      The first batch of 3G cards tested, like the Merlin Qualcomm
      V620, have two functions each supporting a seperate USB OHCI
      host controller, of which it was that first function that is
      wired up to the 3G modem.
      
      Then along comes the Vodafone Mobile Connect 3G/GPRS data card,
      aka "Option GT 3G Quad" as printed on it's rear or "Option N.V.
      GlobeTrotter Fusion Quad Lite" as read with "lspci -v". And it
      has the meaningful functionality in the second CardBus function.
      
      That presents a problem because it was the "ftdi-elan" module
      alone that knows how to communicate to the embedded CardBus slot
      and the "u132-hcd" module alone that knows how to access the
      pcmcia configuration and CardBus accessible memory space. And
      of course, the information about attached (internally hardwired)
      devices is contained within USB configuration embedded somewhere
      within the CardBus card.
      
      If only the "u132-hcd" module probe() interface could return a
      result code that propagated back to the instigating function
      platform_device_register() then the "ftdi-elan" module could
      try an alternative CardBus function.     However in spite of
      the recent changes to the drivers/base/ routines that moved 
      device_attach() from bus_add_device() to bus_attach_device()
      both of those routines lose the "failed to attach" 0 result
      code and thus the calling routine, namely device_add() is
      incapable of propaging the "failed to attach" condition back
      to platform_device_add() and consequently back to the caller
      of platform_device_register()
      
      Experiments show that patching bus_attach_device() to return
      ENODEV fails with the kernel locking up very early during
      boot. But, however, if the patch is restricted to calls from
      platform_device_add() then it does seem to work.
      
      Unfortunately, until the kernel's drivers/base is properly
      modified to propagate -ENODEV back to the caller of
      platform_device_register(), it is necessary to "fix" the
      "ftdi-elan" module by importing knowledge from the 
      "u132-hcd" module. This is the reason for the duplicated
      functionality introduced in this patch.
      Signed-off-by: NTony Olech <tony.olech@elandigitalsystems.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4b87361d
    • V
      USB: OHCI support for PNX8550 · 5151d040
      Vitaly Wool 提交于
      OHCI HCD (Host Controller Driver) for USB. Bus Glue for PNX8550.
      Signed-off-by: NVitaly Wool <vitalywool@gmail.com>
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5151d040