1. 18 4月, 2008 3 次提交
    • B
      ide: remove CONFIG_BLK_DEV_HD_IDE config option (take 2) · 80aa31cb
      Bartlomiej Zolnierkiewicz 提交于
      * Remove CONFIG_BLK_DEV_HD hack from init_hwif_default()
        ("hda=noprobe hdb=noprobe" kernel parameters should be used
        instead if somebody wishes to use the old "hd" driver).
      
      * Make CONFIG_BLK_DEV_HD_ONLY config option available also when
        IDE subsystem is used and update help entry.
      
      * Remove no longer needed CONFIG_BLK_DEV_HD_IDE config option.
      
      v2:
      * Update documentation to suggest "hda=noprobe hdb=noprobe"
        instead of obsoleted "ide0=noprobe".
      
      * Update Documentation/ide/ide.txt.
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      80aa31cb
    • B
      ide: add warm-plug support for IDE devices (take 2) · f74c9141
      Bartlomiej Zolnierkiewicz 提交于
      * Add 'struct class ide_port_class' ('ide_port' class) and a 'struct
        device *portdev' ('ide_port' class device) in ide_hwif_t.
      
      * Register 'ide_port' class in ide_init() and unregister it in
        cleanup_module().
      
      * Create ->portdev in ide_register_port () and unregister it in
        ide_unregister().
      
      * Add "delete_devices" class device attribute for unregistering IDE devices
        on a port and "scan" one for probing+registering IDE devices on a port.
      
      * Add ide_sysfs_register_port() helper for registering "delete_devices"
        and "scan" attributes with ->portdev.  Call it in ide_device_add_all().
      
      * Document IDE warm-plug support in Documentation/ide/warm-plug-howto.txt.
      
      v2:
      * Convert patch from using 'struct class_device' to use 'struct device'.
        (thanks to Kay Sievers for doing it)
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      f74c9141
    • G
      IDE: remove ide=reverse IDE core · a594eeb1
      Greg Kroah-Hartman 提交于
      This option is obsolete and can be removed safely.
      
      It allows us to remove the pci_get_device_reverse() function from the
      PCI core.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      a594eeb1
  2. 16 4月, 2008 2 次提交
  3. 15 4月, 2008 1 次提交
  4. 12 4月, 2008 4 次提交
  5. 09 4月, 2008 1 次提交
  6. 05 4月, 2008 1 次提交
    • P
      cgroups: add cgroup support for enabling controllers at boot time · 8bab8dde
      Paul Menage 提交于
      The effects of cgroup_disable=foo are:
      
      - foo isn't auto-mounted if you mount all cgroups in a single hierarchy
      - foo isn't visible as an individually mountable subsystem
      
      As a result there will only ever be one call to foo->create(), at init time;
      all processes will stay in this group, and the group will never be mounted on
      a visible hierarchy.  Any additional effects (e.g.  not allocating metadata)
      are up to the foo subsystem.
      
      This doesn't handle early_init subsystems (their "disabled" bit isn't set be,
      but it could easily be extended to do so if any of the early_init systems
      wanted it - I think it would just involve some nastier parameter processing
      since it would occur before the command-line argument parser had been run.
      
      Hugh said:
      
        Ballpark figures, I'm trying to get this question out rather than
        processing the exact numbers: CONFIG_CGROUP_MEM_RES_CTLR adds 15% overhead
        to the affected paths, booting with cgroup_disable=memory cuts that back to
        1% overhead (due to slightly bigger struct page).
      
        I'm no expert on distros, they may have no interest whatever in
        CONFIG_CGROUP_MEM_RES_CTLR=y; and the rest of us can easily build with or
        without it, or apply the cgroup_disable=memory patches.
      
      Unix bench's execl test result on x86_64 was
      
      == just after boot without mounting any cgroup fs.==
      mem_cgorup=off : Execl Throughput       43.0     3150.1      732.6
      mem_cgroup=on  : Execl Throughput       43.0     2932.6      682.0
      ==
      
      [lizf@cn.fujitsu.com: fix boot option parsing]
      Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Sudhir Kumar <skumar@linux.vnet.ibm.com>
      Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8bab8dde
  7. 03 4月, 2008 2 次提交
  8. 02 4月, 2008 1 次提交
    • R
      ACPI PM: Restore the 2.6.24 suspend ordering · 7731ce63
      Rafael J. Wysocki 提交于
      Some time ago it turned out that our suspend code ordering broke some
      NVidia-based systems that hung if _PTS was executed with one of the PCI
      devices, specifically a USB controller, in a low power state.
      
      Then, it was noticed that the suspend code ordering was not compliant
      with ACPI 1.0, although it was compliant with ACPI 2.0 (and later), and
      it was argued that the code had to be changed for that reason (ref.
      http://bugzilla.kernel.org/show_bug.cgi?id=9528).
      
      So we did, but evidently we did wrong, because it's now turning out that
      some systems have been broken by this change. Refs:
      	http://bugzilla.kernel.org/show_bug.cgi?id=10340
      	https://bugzilla.novell.com/show_bug.cgi?id=374217#c16
      
      [ I said at that time that something like this might happend, but the
        majority of people involved thought that it was improbable due to the
        necessity to preserve the compliance of hardware with ACPI 1.0. ]
      
      This actually is a quite serious regression from 2.6.24.
      
      Moreover, the ACPI 1.0 ordering of suspend code introduced another issue
      that I have only noticed recently.  Namely, if the suspend of one of
      devices fails, the already suspended devices will be resumed without
      executing _WAK before, which leads to problems on some systems (for
      example, in such situations thermal management is broken on my HP
      nx6325).  Consequently, it also breaks suspend debugging on the affected
      systems.
      
      Note also, that the requirement to execute _PTS before suspending
      devices does not really make sense, because the device in question may
      be put into a low power state at run time for a reason unrelated to a
      system-wide suspend.
      
      For the reasons outlined above, the change of the suspend ordering
      should be reverted, which is done by the patch below.
      
      [ Felix Möller: "I am the reporter from the original Novell Bug:
      
      	https://bugzilla.novell.com/show_bug.cgi?id=374217
      
        I just tried current git head (two hours ago) with the patch (the one
        from the beginning of this thread) from Rafael and without it.  With
        the patch my MacBook does suspend without it does not." ]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Tested-by: NFelix Möller <felix@derklecks.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7731ce63
  9. 01 4月, 2008 1 次提交
  10. 31 3月, 2008 4 次提交
  11. 28 3月, 2008 4 次提交
  12. 27 3月, 2008 2 次提交
  13. 25 3月, 2008 2 次提交
  14. 22 3月, 2008 4 次提交
  15. 20 3月, 2008 1 次提交
  16. 18 3月, 2008 2 次提交
  17. 17 3月, 2008 1 次提交
  18. 16 3月, 2008 1 次提交
    • L
      ACPI: Remove ACPI_CUSTOM_DSDT_INITRD option · 9a9e0d68
      Linus Torvalds 提交于
      This essentially reverts commit 71fc47a9
      ("ACPI: basic initramfs DSDT override support"), because the code simply
      isn't ready.
      
      It did ugly things to the init sequence to populate the rootfs image
      early, but that just ended up showing other problems with the whole
      approach.  The fact is, the VFS layer simply isn't initialized this
      early, and the relevant ACPI code should either run much later, or this
      shouldn't be done at all.
      
      For 2.6.25, we'll just pick the latter option.  We can revisit this
      concept later if necessary.
      
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Tilman Schmidt <tilman@imap.cc>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Eric Piel <eric.piel@tremplin-utc.net>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Markus Gaugusch <dsdt@gaugusch.at>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9a9e0d68
  19. 14 3月, 2008 2 次提交
  20. 13 3月, 2008 1 次提交