1. 14 7月, 2016 1 次提交
    • P
      x86/kernel: Audit and remove any unnecessary uses of module.h · 186f4360
      Paul Gortmaker 提交于
      Historically a lot of these existed because we did not have
      a distinction between what was modular code and what was providing
      support to modules via EXPORT_SYMBOL and friends.  That changed
      when we forked out support for the latter into the export.h file.
      
      This means we should be able to reduce the usage of module.h
      in code that is obj-y Makefile or bool Kconfig.  The advantage
      in doing so is that module.h itself sources about 15 other headers;
      adding significantly to what we feed cpp, and it can obscure what
      headers we are effectively using.
      
      Since module.h was the source for init.h (for __init) and for
      export.h (for EXPORT_SYMBOL) we consider each obj-y/bool instance
      for the presence of either and replace as needed.  Build testing
      revealed some implicit header usage that was fixed up accordingly.
      
      Note that some bool/obj-y instances remain since module.h is
      the header for some exception table entry stuff, and for things
      like __init_or_module (code that is tossed when MODULES=n).
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160714001901.31603-4-paul.gortmaker@windriver.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      186f4360
  2. 01 2月, 2016 1 次提交
    • H
      x86/cpufeature: Use enum cpuid_leafs instead of magic numbers · 16aaa537
      Huaitong Han 提交于
      Most of the magic numbers in x86_capability[] have been converted to
      'enum cpuid_leafs', and this patch updates the remaining part.
      Signed-off-by: NHuaitong Han <huaitong.han@intel.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Alexander Kuleshov <kuleshovmail@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hector Marco-Gisbert <hecmargi@upv.es>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: lguest@lists.ozlabs.org
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1453750913-4781-3-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      16aaa537
  3. 24 4月, 2015 2 次提交
    • T
      x86: Cleanup irq_domain ops · f7a0c786
      Thomas Gleixner 提交于
      We have 3 identical copies of the ioapic domain ops for acpi, mpparse,
      and sfi. Have a global one in the io_apic code and be done with it.
      
      To avoid include hell in io_apic.h, create a private irqdomain header
      and include the generic irqdomain header from there.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: David Cohen <david.a.cohen@linux.intel.com>
      Cc: Sander Eikelenboom <linux@eikelenboom.it>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: sfi-devel@simplefirmware.org
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Herring <robh@kernel.org>
      Cc: x86@kernel.org
      Link: http://lkml.kernel.org/r/1428978610-28986-32-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      f7a0c786
    • J
      x86/irq: Convert IOAPIC to use hierarchical irqdomain interfaces · d32932d0
      Jiang Liu 提交于
      Convert IOAPIC driver to support and use hierarchical irqdomain
      interfaces.  It's a little big, but would break bisecting if we split
      it into multiple patches.
      
      Fold in a patch from Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      to make it bisectable.
      http://lkml.org/lkml/2014/12/10/622Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Tested-by: NJoerg Roedel <jroedel@suse.de>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Sander Eikelenboom <linux@eikelenboom.it>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: sfi-devel@simplefirmware.org
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Herring <robh@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: David Cohen <david.a.cohen@linux.intel.com>
      Link: http://lkml.kernel.org/r/1428905519-23704-38-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      d32932d0
  4. 31 7月, 2014 1 次提交
  5. 22 6月, 2014 5 次提交
  6. 30 5月, 2012 1 次提交
    • B
      x86: print physical addresses consistently with other parts of kernel · 365811d6
      Bjorn Helgaas 提交于
      Print physical address info in a style consistent with the %pR style used
      elsewhere in the kernel.  For example:
      
          -found SMP MP-table at [ffff8800000fce90] fce90
          +found SMP MP-table at [mem 0x000fce90-0x000fce9f] mapped at [ffff8800000fce90]
          -initial memory mapped : 0 - 20000000
          +initial memory mapped: [mem 0x00000000-0x1fffffff]
          -Base memory trampoline at [ffff88000009c000] 9c000 size 8192
          +Base memory trampoline [mem 0x0009c000-0x0009dfff] mapped at [ffff88000009c000]
          -SRAT: Node 0 PXM 0 0-80000000
          +SRAT: Node 0 PXM 0 [mem 0x00000000-0x7fffffff]
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      365811d6
  7. 18 5月, 2012 1 次提交
    • P
      MCA: delete all remaining traces of microchannel bus support. · bb8187d3
      Paul Gortmaker 提交于
      Hardware with MCA bus is limited to 386 and 486 class machines
      that are now 20+ years old and typically with less than 32MB
      of memory.  A quick search on the internet, and you see that
      even the MCA hobbyist/enthusiast community has lost interest
      in the early 2000 era and never really even moved ahead from
      the 2.4 kernels to the 2.6 series.
      
      This deletes anything remaining related to CONFIG_MCA from core
      kernel code and from the x86 architecture.  There is no point in
      carrying this any further into the future.
      
      One complication to watch for is inadvertently scooping up
      stuff relating to machine check, since there is overlap in
      the TLA name space (e.g. arch/x86/boot/mca.c).
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: James Bottomley <JBottomley@Parallels.com>
      Cc: x86@kernel.org
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      bb8187d3
  8. 09 5月, 2012 1 次提交
  9. 05 12月, 2011 1 次提交
  10. 15 7月, 2011 2 次提交
  11. 20 5月, 2011 1 次提交
  12. 04 4月, 2011 1 次提交
  13. 24 3月, 2011 1 次提交
  14. 22 3月, 2011 1 次提交
  15. 18 3月, 2011 1 次提交
  16. 10 12月, 2010 4 次提交
  17. 28 8月, 2010 1 次提交
    • Y
      x86: Use memblock to replace early_res · 72d7c3b3
      Yinghai Lu 提交于
      1. replace find_e820_area with memblock_find_in_range
      2. replace reserve_early with memblock_x86_reserve_range
      3. replace free_early with memblock_x86_free_range.
      4. NO_BOOTMEM will switch to use memblock too.
      5. use _e820, _early wrap in the patch, in following patch, will
         replace them all
      6. because memblock_x86_free_range support partial free, we can remove some special care
      7. Need to make sure that memblock_find_in_range() is called after memblock_x86_fill()
         so adjust some calling later in setup.c::setup_arch()
         -- corruption_check and mptable_update
      
      -v2: Move reserve_brk() early
          Before fill_memblock_area, to avoid overlap between brk and memblock_find_in_range()
          that could happen We have more then 128 RAM entry in E820 tables, and
          memblock_x86_fill() could use memblock_find_in_range() to find a new place for
          memblock.memory.region array.
          and We don't need to use extend_brk() after fill_memblock_area()
          So move reserve_brk() early before fill_memblock_area().
      -v3: Move find_smp_config early
          To make sure memblock_find_in_range not find wrong place, if BIOS doesn't put mptable
          in right place.
      -v4: Treat RESERVED_KERN as RAM in memblock.memory. and they are already in
          memblock.reserved already..
          use __NOT_KEEP_MEMBLOCK to make sure memblock related code could be freed later.
      -v5: Generic version __memblock_find_in_range() is going from high to low, and for 32bit
          active_region for 32bit does include high pages
          need to replace the limit with memblock.default_alloc_limit, aka get_max_mapped()
      -v6: Use current_limit instead
      -v7: check with MEMBLOCK_ERROR instead of -1ULL or -1L
      -v8: Set memblock_can_resize early to handle EFI with more RAM entries
      -v9: update after kmemleak changes in mainline
      Suggested-by: NDavid S. Miller <davem@davemloft.net>
      Suggested-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Suggested-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      72d7c3b3
  18. 06 8月, 2010 1 次提交
    • E
      x86, apic: Map the local apic when parsing the MP table. · 5989cd6a
      Eric W. Biederman 提交于
      This fixes a regression in 2.6.35 from 2.6.34, that is
      present for select models of Intel cpus when people are
      using an MP table.
      
      The commit cf7500c0
      "x86, ioapic: In mpparse use mp_register_ioapic" started
      calling mp_register_ioapic from MP_ioapic_info.  An extremely
      simple change that was obviously correct.  Unfortunately
      mp_register_ioapic did just a little more than the previous
      hand crafted code and so we gained this call path.
      
      The problem call path is:
      MP_ioapic_info()
        mp_register_ioapic()
         io_apic_unique_id()
           io_apic_get_unique_id()
             get_physical_broadcast()
               modern_apic()
                 lapic_get_version()
                   apic_read(APIC_LVR)
      
      Which turned out to be a problem because the local apic
      was not mapped, at that point, unlike the similar point
      in the ACPI parsing code.
      
      This problem is fixed by mapping the local apic when
      parsing the mptable as soon as we reasonably can.
      
      Looking at the number of places we setup the fixmap for
      the local apic, I see some serious simplification opportunities.
      For the moment except for not duplicating the setting up of the
      fixmap in init_apic_mappings, I have not acted on them.
      
      The regression from 2.6.34 is tracked in bug
      https://bugzilla.kernel.org/show_bug.cgi?id=16173
      
      Cc: <stable@kernel.org> 2.6.35
      Reported-by: NDavid Hill <hilld@binarystorm.net>
      Reported-by: NTvrtko Ursulin <tvrtko.ursulin@sophos.com>
      Tested-by: NTvrtko Ursulin <tvrtko.ursulin@sophos.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <m1eiee86jg.fsf_-_@fess.ebiederm.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      5989cd6a
  19. 10 6月, 2010 1 次提交
    • E
      x86, irq: Rename gsi_end gsi_top, and fix off by one errors · a4384df3
      Eric W. Biederman 提交于
      When I introduced the global variable gsi_end I thought gsi_end on
      io_apics was one past the end of the gsi range for the io_apic.  After
      it was pointed out the the range on io_apics was inclusive I changed
      my global variable to match.  That was a big mistake.  Inclusive
      semantics without a range start cannot describe the case when no gsi's
      are allocated.  Describing the case where no gsi's are allocated is
      important in sfi.c and mpparse.c so that we can assign gsi numbers
      instead of blindly copying the gsi assignments the BIOS has done as we
      do in the acpi case.
      
      To keep from getting the global variable confused with the gsi range
      end rename it gsi_top.
      
      To allow describing the case where no gsi's are allocated have gsi_top
      be one place the highest gsi number seen in the system.
      
      This fixes an off by one bug in sfi.c:
      Reported-by: Njacob pan <jacob.jun.pan@linux.intel.com>
      
      This fixes the same off by one bug in mpparse.c:
      
      This fixes an off unreachable by one bug in acpi/boot.c:irq_to_gsi
      Reported-by: NYinghai <yinghai.lu@oracle.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <m17hm9jre7.fsf_-_@fess.ebiederm.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      a4384df3
  20. 05 5月, 2010 1 次提交
    • E
      x86, ioapic: In mpparse use mp_register_ioapic · cf7500c0
      Eric W. Biederman 提交于
      Long ago MP_ioapic_info was the primary way of setting up our
      ioapic data structures and mp_register_ioapic was a compatibility
      shim for acpi code.  Now the situation is reversed and
      and mp_register_ioapic is the primary way of setting up our
      ioapic data structures.
      
      Keep the setting up of ioapic data structures uniform by
      having mp_register_ioapic call mp_register_ioapic.
      
      This changes a few fields:
      
      - type: is now hardset to MP_IOAPIC but type had to
        bey MP_IOAPIC or MP_ioapic_info would not have been called.
      
      - flags: is now hard coded to MPC_APIC_USABLE.
        We require flags to contain at least MPC_APIC_USEBLE in
        MP_ioapic_info and we don't ever examine flags so dropping
        a few flags that might possibly exist that we have never
        used is harmless.
      
      - apicaddr: Unchanged
      
      - apicver: Read from the ioapic instead of using the cached
        hardware value in the MP table.  The real hardware value
        will be more accurate.
      
      - apicid: Now verified to be unique and changed if it is not.
        If the BIOS got this right this is a noop.  If the BIOS did
        not fixing things appears to be the better solution.
      
      This adds gsi_base and gsi_end values to our ioapics defined with
      the mpatable, which will make our lives simpler later since
      we can always assume gsi_base and gsi_end are valid.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <1269936436-7039-10-git-send-email-ebiederm@xmission.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      cf7500c0
  21. 02 4月, 2010 1 次提交
  22. 10 2月, 2010 1 次提交
    • S
      x86, apic: Don't use logical-flat mode when CPU hotplug may exceed 8 CPUs · 681ee44d
      Suresh Siddha 提交于
      We need to fall back from logical-flat APIC mode to physical-flat mode
      when we have more than 8 CPUs.  However, in the presence of CPU
      hotplug(with bios listing not enabled but possible cpus as disabled cpus in
      MADT), we have to consider the number of possible CPUs rather than
      the number of current CPUs; otherwise we may cross the 8-CPU boundary
      when CPUs are added later.
      
      32bit apic code can use more cleanups (like the removal of vendor checks in
      32bit default_setup_apic_routing()) and more unifications with 64bit code.
      Yinghai has some patches in works already. This patch addresses the boot issue
      that is reported in the virtualization guest context.
      
      [ hpa: incorporated function annotation feedback from Yinghai Lu ]
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <1265767304.2833.19.camel@sbs-t61.sc.intel.com>
      Acked-by: NShaohui Zheng <shaohui.zheng@intel.com>
      Reviewed-by: NYinghai Lu <yinghai@kernel.org>
      Cc: <stable@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      681ee44d
  23. 11 12月, 2009 1 次提交
    • Y
      x86: Use find_e820() instead of hard coded trampoline address · 893f38d1
      Yinghai Lu 提交于
      Jens found the following crash/regression:
      
      [    0.000000] found SMP MP-table at [ffff8800000fdd80] fdd80
      [    0.000000] Kernel panic - not syncing: Overlapping early reservations 12-f011 MP-table mpc to 0-fff BIOS data page
      
      and
      
      [    0.000000] Kernel panic - not syncing: Overlapping early reservations 12-f011 MP-table mpc to 6000-7fff TRAMPOLINE
      
      and bisected it to b24c2a92 ("x86: Move find_smp_config()
      earlier and avoid bootmem usage").
      
      It turns out the BIOS is using the first 64k for mptable,
      without reserving it.
      
      So try to find good range for the real-mode trampoline instead of
      hard coding it, in case some bios tries to use that range for sth.
      Reported-by: NJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Tested-by: NJens Axboe <jens.axboe@oracle.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      LKML-Reference: <4B21630A.6000308@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      893f38d1
  24. 24 11月, 2009 1 次提交
  25. 31 8月, 2009 1 次提交
  26. 27 8月, 2009 5 次提交
  27. 26 8月, 2009 1 次提交