1. 22 6月, 2016 3 次提交
  2. 06 5月, 2016 1 次提交
  3. 19 4月, 2016 2 次提交
    • L
      ACPI / tables: Convert initrd table override to table upgrade mechanism · 5d881327
      Lv Zheng 提交于
      This patch converts the initrd table override mechanism to the table
      upgrade mechanism by restricting its usage to the tables released with
      compatibility and more recent revision.
      
      This use case has been encouraged by the ACPI specification:
      
       1. OEMID:
          An OEM-supplied string that identifies the OEM.
      
       2. OEM Table ID:
          An OEM-supplied string that the OEM uses to identify the particular data
          table. This field is particularly useful when defining a definition
          block to distinguish definition block functions. OEM assigns each
          dissimilar table a new OEM Table Id.
      
       3. OEM Revision:
          An OEM-supplied revision number. Larger numbers are assumed to be newer
          revisions.
      
      For OEMs, good practices will ensure consistency when assigning OEMID and
      OEM Table ID fields in any table. The intent of these fields is to allow
      for a binary control system that support services can use. Because many
      support function can be automated, it is useful when a tool can
      programatically determine which table release is a compatible and more
      recent revision of a prior table on the same OEMID and OEM Table ID.
      
      The facility can now be used by the vendors to upgrade wrong tables for bug
      fixing purpose, thus lockdep disabling taint is not suitable for it and it
      should be a default 'y' option to implement the spec encouraged use case.
      
      Note that, by implementing table upgrade inside of ACPICA itself, it is
      possible to remove acpi_table_initrd_override() and tables can be upgraded
      by acpi_install_table() automatically. Though current ACPICA impelentation
      hasn't implemented this, this patched changes the table flag setting timing
      to allow this to be implemented in ACPICA without changing the code here.
      
      Documentation of initrd override mechanism is upgraded accordingly.
      Original-by: NOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5d881327
    • L
      ACPI / tables: Move table override mechanisms to tables.c · 5ae74f2c
      Lv Zheng 提交于
      This patch moves acpi_os_table_override() and
      acpi_os_physical_table_override() to tables.c.
      
      Along with the mechanisms, acpi_initrd_initialize_tables() is also moved to
      tables.c to form a static function. The following functions are renamed
      according to this change:
       1. acpi_initrd_override() -> renamed to early_acpi_table_init(), which
          invokes acpi_table_initrd_init()
       2. acpi_os_physical_table_override() -> which invokes
          acpi_table_initrd_override()
       3. acpi_initialize_initrd_tables() -> renamed to acpi_table_initrd_scan()
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5ae74f2c
  4. 10 3月, 2016 2 次提交
  5. 15 10月, 2015 2 次提交
  6. 08 7月, 2015 1 次提交
  7. 25 3月, 2015 2 次提交
  8. 27 11月, 2014 2 次提交
  9. 17 6月, 2014 1 次提交
  10. 01 6月, 2014 1 次提交
    • L
      ACPI: Fix x86 regression related to early mapping size limitation · 4fc0a7e8
      Lv Zheng 提交于
      The following warning message is triggered:
       WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:136 __early_ioremap+0x11f/0x1f2()
       Modules linked in:
       CPU: 0 PID: 0 Comm: swapper Not tainted 3.15.0-rc1-00017-g86dfc6f3-dirty #298
       Hardware name: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x036.091920111209 09/19/2011
        0000000000000009 ffffffff81b75c40 ffffffff817c627b 0000000000000000
        ffffffff81b75c78 ffffffff81067b5d 000000000000007b 8000000000000563
        00000000b96b20dc 0000000000000001 ffffffffff300e0c ffffffff81b75c88
       Call Trace:
        [<ffffffff817c627b>] dump_stack+0x45/0x56
        [<ffffffff81067b5d>] warn_slowpath_common+0x7d/0xa0
        [<ffffffff81067c3a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff81d4b9d5>] __early_ioremap+0x11f/0x1f2
        [<ffffffff81d4bc5b>] early_ioremap+0x13/0x15
        [<ffffffff81d2b8f3>] __acpi_map_table+0x13/0x18
        [<ffffffff817b8d1a>] acpi_os_map_memory+0x26/0x14e
        [<ffffffff813ff018>] acpi_tb_acquire_table+0x42/0x70
        [<ffffffff813ff086>] acpi_tb_validate_table+0x27/0x37
        [<ffffffff813ff0e5>] acpi_tb_verify_table+0x22/0xd8
        [<ffffffff813ff6a8>] acpi_tb_install_non_fixed_table+0x60/0x1c9
        [<ffffffff81d61024>] acpi_tb_parse_root_table+0x218/0x26a
        [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
        [<ffffffff81d610cd>] acpi_initialize_tables+0x57/0x59
        [<ffffffff81d5f25d>] acpi_table_init+0x1b/0x99
        [<ffffffff81d2bca0>] acpi_boot_table_init+0x1e/0x85
        [<ffffffff81d23043>] setup_arch+0x99d/0xcc6
        [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
        [<ffffffff81d1bbbe>] start_kernel+0x8b/0x415
        [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
        [<ffffffff81d1b5ee>] x86_64_start_reservations+0x2a/0x2c
        [<ffffffff81d1b72e>] x86_64_start_kernel+0x13e/0x14d
       ---[ end trace 11ae599a1898f4e7 ]---
      when installing the following table during early stage:
       ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL  S2600CP  00004000 INTL 20100331)
      The regression is caused by the size limitation of the x86 early IO mapping.
      
      The root cause is:
       1. ACPICA doesn't split IO memory mapping and table mapping;
       2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map
          mechanism during early boot stage, which is more suitable for only IO
          mappings.
      
      This patch fixes this issue by utilizing acpi_gbl_verify_table_checksum to
      disable the table mapping during early stage and enabling it again for the
      late stage. In this way, the normal code path is not affected. Then after
      the code related to the root cause is cleaned up, the early checksum
      verification can be easily re-enabled.
      
      A new boot parameter - acpi_force_table_verification is introduced for
      the platforms that require the checksum verification to stop loading bad
      tables.
      
      This fix also covers the checksum verification for the table overrides. Now
      large tables can also be overridden using the initrd override mechanism.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Reported-and-tested-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4fc0a7e8
  11. 02 3月, 2014 1 次提交
  12. 06 1月, 2014 2 次提交
  13. 07 12月, 2013 1 次提交
  14. 11 1月, 2013 1 次提交
  15. 07 10月, 2012 1 次提交
  16. 15 3月, 2010 1 次提交
    • L
      ACPI: delete the "acpi=ht" boot option · 68ca4069
      Len Brown 提交于
      acpi=ht was important in 2003 -- before ACPI was
      universally deployed and enabled by default in
      the major Linux distributions.
      
      At that time, there were a fair number of people who
      or chose to, or needed to, run with acpi=off,
      yet also wanted access to Hyper-threading.
      
      Today we find that many invocations of "acpi=ht"
      are accidental, and thus is it possible that it
      is doing more harm than good.
      
      In 2.6.34, we warn on invocation of acpi=ht.
      In 2.6.35, we delete the boot option.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      68ca4069
  17. 18 2月, 2010 1 次提交
  18. 29 8月, 2009 1 次提交
  19. 04 4月, 2009 1 次提交
    • S
      x86, ACPI: add support for x2apic ACPI extensions · 7237d3de
      Suresh Siddha 提交于
      All logical processors with APIC ID values of 255 and greater will have their
      APIC reported through Processor X2APIC structure (type-9 entry type) and all
      logical processors with APIC ID less than 255 will have their APIC reported
      through legacy Processor Local APIC (type-0 entry type) only. This is the
      same case even for NMI structure reporting.
          
      The Processor X2APIC Affinity structure provides the association between the
      X2APIC ID of a logical processor and the proximity domain to which the logical
      processor belongs.
          
      For OSPM, Procssor IDs outside the 0-254 range are to be declared as Device()
      objects in the ACPI namespace.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      7237d3de
  20. 09 2月, 2009 1 次提交
    • Y
      acpi/x86: introduce __apci_map_table, v4 · 7d97277b
      Yinghai Lu 提交于
      to prevent wrongly overwriting fixmap that still want to use.
      
      ACPI used to rely on low mappings being all linearly mapped and
      grew a habit: it never really unmapped certain kinds of tables
      after use.
      
      This can cause problems - for example the hypothetical case
      when some spurious access still references it.
      
      v2: remove prev_map and prev_size in __apci_map_table
      v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to
      early_acpi_os_unmap_memory
      v4: fix typo in one acpi_get_table_with_size calling
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Acked-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7d97277b
  21. 07 2月, 2009 1 次提交
    • L
      ACPI: disable ACPI cleanly when bad RSDP found · 9e3a9d1e
      Len Brown 提交于
      When ACPI is disabled in the BIOS of this VIA C3 box,
      it invalidates the RSDP, which Linux notices:
      
      ACPI Error (tbxfroot-0218): A valid RSDP was not found [20080926]
      
      Bug Linux neglected to disable ACPI at that stage,
      and later scribbled on smp_found_config:
      
      ACPI: No APIC-table, disabling MPS
      
      But this box doesn't run well in legacy PIC mode,
      it needed IOAPIC mode to perform correctly:
      
      http://lkml.org/lkml/2009/2/5/39
      
      So exit ACPI mode cleanly when we first detect
      that it is hopeless.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      9e3a9d1e
  22. 21 8月, 2008 1 次提交
  23. 31 3月, 2007 1 次提交
  24. 15 3月, 2007 1 次提交
  25. 11 3月, 2007 1 次提交
  26. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  27. 13 2月, 2007 3 次提交
  28. 03 2月, 2007 3 次提交