1. 08 10月, 2014 1 次提交
  2. 31 7月, 2014 7 次提交
  3. 09 2月, 2014 1 次提交
  4. 15 7月, 2013 1 次提交
    • P
      x86: delete __cpuinit usage from all x86 files · 148f9bb8
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      are flagged as __cpuinit  -- so if we remove the __cpuinit from
      arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      content into no-ops as early as possible, since that will get rid
      of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the arch/x86 uses of the __cpuinit macros from
      all C files.  x86 only had the one __CPUINIT used in assembly files,
      and it wasn't paired off with a .previous or a __FINIT, so we can
      delete it directly w/o any corresponding additional change there.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      148f9bb8
  5. 08 12月, 2012 1 次提交
  6. 17 11月, 2012 1 次提交
  7. 06 10月, 2012 1 次提交
  8. 14 6月, 2012 1 次提交
  9. 08 6月, 2012 1 次提交
  10. 06 6月, 2012 2 次提交
  11. 18 5月, 2012 1 次提交
  12. 17 4月, 2012 1 次提交
  13. 23 3月, 2012 1 次提交
    • S
      x86/apic: Add separate apic_id_valid() functions for selected apic drivers · b7157acf
      Steffen Persvold 提交于
      As suggested by Suresh Siddha and Yinghai Lu:
      
      For x2apic pre-enabled systems, apic driver is set already early
      through early_acpi_boot_init()/early_acpi_process_madt()/
      acpi_parse_madt()/default_acpi_madt_oem_check() path so that
      apic_id_valid() checking will be sufficient during MADT and SRAT
      parsing.
      
      For non-x2apic pre-enabled systems, all apic ids should be less
      than 255.
      
      This allows us to substitute the checks in
      arch/x86/kernel/acpi/boot.c::acpi_parse_x2apic() and
      arch/x86/mm/srat.c::acpi_numa_x2apic_affinity_init() with
      apic->apic_id_valid().
      
      In addition we can avoid feigning the x2apic cpu feature in the
      NumaChip apic code.
      
      The following apic drivers have separate apic_id_valid()
      functions which will accept x2apic type IDs :
      
       x2apic_phys
       x2apic_cluster
       x2apic_uv_x
       apic_numachip
      Signed-off-by: NSteffen Persvold <sp@numascale.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Daniel J Blueman <daniel@numascale-asia.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Jack Steiner <steiner@sgi.com>
      Link: http://lkml.kernel.org/r/1331925935-13372-1-git-send-email-sp@numascale.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b7157acf
  14. 14 3月, 2012 1 次提交
  15. 06 12月, 2011 1 次提交