1. 21 6月, 2008 1 次提交
  2. 21 4月, 2008 1 次提交
  3. 20 4月, 2008 1 次提交
    • R
      PM: Remove destroy_suspended_device() · b844eba2
      Rafael J. Wysocki 提交于
      After 2.6.24 there was a plan to make the PM core acquire all device
      semaphores during a suspend/hibernation to protect itself from
      concurrent operations involving device objects.  That proved to be
      too heavy-handed and we found a better way to achieve the goal, but
      before it happened, we had introduced the functions
      device_pm_schedule_removal() and destroy_suspended_device() to allow
      drivers to "safely" destroy a suspended device and we had adapted some
      drivers to use them.  Now that these functions are no longer necessary,
      it seems reasonable to remove them and modify their users to use the
      normal device unregistration instead.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b844eba2
  4. 17 4月, 2008 1 次提交
  5. 25 3月, 2008 1 次提交
    • D
      hw_random doc updates · 537878d2
      David Brownell 提交于
      Update documentation for the hw_random support to be current:
      
       - Documentation/hw_random.txt has been updated to reflect the
         current code:  it's a framework now, a "core" with a small
         sysfs interface, that hardware-specific drivers plug in to.
         Text specific to Intel hardware is now at the end.
      
       - Kconfig now references the Documentation/hw_random.txt file
         and better explains what this really does.
      
      Both chunks of documentation now higlight the fact that the kernel entropy
      pool is maintained by "rngd", and this driver has nothing directly to do with
      that important task.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      537878d2
  6. 07 2月, 2008 1 次提交
  7. 06 2月, 2008 1 次提交
  8. 11 1月, 2008 2 次提交
  9. 30 11月, 2007 1 次提交
  10. 20 10月, 2007 1 次提交
  11. 22 7月, 2007 1 次提交
  12. 17 7月, 2007 1 次提交
  13. 10 5月, 2007 1 次提交
  14. 09 5月, 2007 1 次提交
    • P
      Use stop_machine_run in the Intel RNG driver · ee527cd3
      Prarit Bhargava 提交于
      Replace call_smp_function with stop_machine_run in the Intel RNG driver.
      
      CPU A has done read_lock(&lock)
      CPU B has done write_lock_irq(&lock) and is waiting for A to release the lock.
      
      A third CPU calls call_smp_function and issues the IPI.  CPU A takes CPU
      C's IPI.  CPU B is waiting with interrupts disabled and does not see the
      IPI.  CPU C is stuck waiting for CPU B to respond to the IPI.
      
      Deadlock.
      
      The solution is to use stop_machine_run instead of call_smp_function
      (call_smp_function should not be called in situations where the CPUs may be
      suspended).
      
      [haruo.tomita@toshiba.co.jp: fix a typo in mod_init()]
      [haruo.tomita@toshiba.co.jp: fix memory leak]
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: Jan Beulich <jbeulich@novell.com>
      Cc: "Tomita, Haruo" <haruo.tomita@toshiba.co.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ee527cd3
  15. 03 5月, 2007 1 次提交
    • J
      PCI: Cleanup the includes of <linux/pci.h> · 6473d160
      Jean Delvare 提交于
      I noticed that many source files include <linux/pci.h> while they do
      not appear to need it. Here is an attempt to clean it all up.
      
      In order to find all possibly affected files, I searched for all
      files including <linux/pci.h> but without any other occurence of "pci"
      or "PCI". I removed the include statement from all of these, then I
      compiled an allmodconfig kernel on both i386 and x86_64 and fixed the
      false positives manually.
      
      My tests covered 66% of the affected files, so there could be false
      positives remaining. Untested files are:
      
      arch/alpha/kernel/err_common.c
      arch/alpha/kernel/err_ev6.c
      arch/alpha/kernel/err_ev7.c
      arch/ia64/sn/kernel/huberror.c
      arch/ia64/sn/kernel/xpnet.c
      arch/m68knommu/kernel/dma.c
      arch/mips/lib/iomap.c
      arch/powerpc/platforms/pseries/ras.c
      arch/ppc/8260_io/enet.c
      arch/ppc/8260_io/fcc_enet.c
      arch/ppc/8xx_io/enet.c
      arch/ppc/syslib/ppc4xx_sgdma.c
      arch/sh64/mach-cayman/iomap.c
      arch/xtensa/kernel/xtensa_ksyms.c
      arch/xtensa/platform-iss/setup.c
      drivers/i2c/busses/i2c-at91.c
      drivers/i2c/busses/i2c-mpc.c
      drivers/media/video/saa711x.c
      drivers/misc/hdpuftrs/hdpu_cpustate.c
      drivers/misc/hdpuftrs/hdpu_nexus.c
      drivers/net/au1000_eth.c
      drivers/net/fec_8xx/fec_main.c
      drivers/net/fec_8xx/fec_mii.c
      drivers/net/fs_enet/fs_enet-main.c
      drivers/net/fs_enet/mac-fcc.c
      drivers/net/fs_enet/mac-fec.c
      drivers/net/fs_enet/mac-scc.c
      drivers/net/fs_enet/mii-bitbang.c
      drivers/net/fs_enet/mii-fec.c
      drivers/net/ibm_emac/ibm_emac_core.c
      drivers/net/lasi_82596.c
      drivers/parisc/hppb.c
      drivers/sbus/sbus.c
      drivers/video/g364fb.c
      drivers/video/platinumfb.c
      drivers/video/stifb.c
      drivers/video/valkyriefb.c
      include/asm-arm/arch-ixp4xx/dma.h
      sound/oss/au1550_ac97.c
      
      I would welcome test reports for these files. I am fine with removing
      the untested files from the patch if the general opinion is that these
      changes aren't safe. The tested part would still be nice to have.
      
      Note that this patch depends on another header fixup patch I submitted
      to LKML yesterday:
        [PATCH] scatterlist.h needs types.h
        http://lkml.org/lkml/2007/3/01/141Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6473d160
  16. 13 2月, 2007 1 次提交
  17. 12 1月, 2007 2 次提交
  18. 08 12月, 2006 1 次提交
  19. 04 12月, 2006 1 次提交
  20. 02 12月, 2006 1 次提交
  21. 04 10月, 2006 2 次提交
  22. 30 9月, 2006 1 次提交
    • J
      [PATCH] fix Intel RNG detection · c24c95a0
      Jan Beulich 提交于
      Previously, since determination whether there was an Intel random number
      generator was based on a single bit, on systems with a matching bridge
      device but without a firmware hub, there was a 50% chance that the code
      would incorrectly decide that the system had an RNG.  This patch adds
      detection of the firmware hub to better qualify the existence of an RNG.
      
      There is one issue with the patch: I was unable to determine the LPC
      equivalent for the PCI bridge 8086:2430 (since the old code didn't care
      about which of the many devices provided by the ICH/ESB it was chose to use
      the PCI bridge device, but the FWH settings live in the LPC device, so the
      device list needed to be changed).
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NMichael Buesch <mb@bu3sch.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c24c95a0
  23. 06 8月, 2006 1 次提交
  24. 01 8月, 2006 2 次提交
  25. 04 7月, 2006 1 次提交
  26. 27 6月, 2006 7 次提交