1. 11 10月, 2008 38 次提交
  2. 10 10月, 2008 2 次提交
    • L
      Merge phase #1 of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip · d403a648
      Linus Torvalds 提交于
      This merges phase 1 of the x86 tree, which is a collection of branches:
      
        x86/alternatives, x86/cleanups, x86/commandline, x86/crashdump,
        x86/debug, x86/defconfig, x86/doc, x86/exports, x86/fpu, x86/gart,
        x86/idle, x86/mm, x86/mtrr, x86/nmi-watchdog, x86/oprofile,
        x86/paravirt, x86/reboot, x86/sparse-fixes, x86/tsc, x86/urgent and
        x86/vmalloc
      
      and as Ingo says: "these are the easiest, purely independent x86 topics
      with no conflicts, in one nice Octopus merge".
      
      * 'x86-v28-for-linus-phase1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (147 commits)
        x86: mtrr_cleanup: treat WRPROT as UNCACHEABLE
        x86: mtrr_cleanup: first 1M may be covered in var mtrrs
        x86: mtrr_cleanup: print out correct type v2
        x86: trivial printk fix in efi.c
        x86, debug: mtrr_cleanup print out var mtrr before change it
        x86: mtrr_cleanup try gran_size to less than 1M, v3
        x86: mtrr_cleanup try gran_size to less than 1M, cleanup
        x86: change MTRR_SANITIZER to def_bool y
        x86, debug printouts: IOMMU setup failures should not be KERN_ERR
        x86: export set_memory_ro and set_memory_rw
        x86: mtrr_cleanup try gran_size to less than 1M
        x86: mtrr_cleanup prepare to make gran_size to less 1M
        x86: mtrr_cleanup safe to get more spare regs now
        x86_64: be less annoying on boot, v2
        x86: mtrr_cleanup hole size should be less than half of chunk_size, v2
        x86: add mtrr_cleanup_debug command line
        x86: mtrr_cleanup optimization, v2
        x86: don't need to go to chunksize to 4G
        x86_64: be less annoying on boot
        x86, olpc: fix endian bug in openfirmware workaround
        ...
      d403a648
    • L
      PnP: move pnpacpi/pnpbios_init to after PCI init · ed458df4
      Linus Torvalds 提交于
      We already did that a long time ago for pnp_system_init, but
      pnpacpi_init and pnpbios_init remained as subsys_initcalls, and get
      linked into the kernel before the arch-specific routines that finalize
      the PCI resources (pci_subsys_init).
      
      This means that the PnP routines would either register their resources
      before the PCI layer could, or would be unable to check whether a PCI
      resource had already been registered.  Both are problematic.
      
      I wanted to do this before 2.6.27, but every time we change something
      like this, something breaks.  That said, _every_ single time we trust
      some firmware (like PnP tables) more than we trust the hardware itself
      (like PCI probing), the problems have been worse.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ed458df4