1. 02 7月, 2015 3 次提交
    • B
      ACPICA: De-macroize calls to standard C library functions · 4fa4616e
      Bob Moore 提交于
      ACPICA commit 3b1026e0bdd3c32eb6d5d313f3ba0b1fee7597b4
      ACPICA commit 00f0dc83f5cfca53b27a3213ae0d7719b88c2d6b
      ACPICA commit 47d22a738d0e19fd241ffe4e3e9d4e198e4afc69
      
      Across all of ACPICA. Replace C library macros such as ACPI_STRLEN with the
      standard names such as strlen. The original purpose for these macros is
      long since obsolete.
      Also cast various invocations as necessary. Bob Moore, Jung-uk Kim, Lv Zheng.
      
      Link: https://github.com/acpica/acpica/commit/3b1026e0
      Link: https://github.com/acpica/acpica/commit/00f0dc83
      Link: https://github.com/acpica/acpica/commit/47d22a73Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NJung-uk Kim <jkim@FreeBSD.org>
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4fa4616e
    • L
      ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS · f06147f9
      Lv Zheng 提交于
      ACPICA commit 368eb60778b27b6ae94d3658ddc902ca1342a963
      ACPICA commit 70f62a80d65515e1285fdeeb50d94ee6f07df4bd
      ACPICA commit a04dbfa308a48ab0b2d10519c54a6c533c5c8949
      ACPICA commit ebd544ed24c5a4faba11f265e228b7a821a729f5
      
      The following commit is reported to have broken s2ram on some platforms:
       Commit: 0249ed24
       ACPICA: Add option to favor 32-bit FADT addresses.
      The platform reports 2 FACS tables (which is not allowed by ACPI
      specification) and the new 32-bit address favor rule forces OSPMs to use
      the FACS table reported via FADT's X_FIRMWARE_CTRL field.
      
      The root cause of the reported bug might be one of the followings:
      1. BIOS may favor the 64-bit firmware waking vector address when the
         version of the FACS is greater than 0 and Linux currently only supports
         resuming from the real mode, so the 64-bit firmware waking vector has
         never been set and might be invalid to BIOS while the commit enables
         higher version FACS.
      2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the
         FADT while the commit doesn't set the firmware waking vector address of
         the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking
         vector address of the FACS reported by "X_FIRMWARE_CTRL".
      
      This patch excludes the cases that can trigger the bugs caused by the root
      cause 2.
      
      There is no handshaking mechanism can be used by OSPM to tell BIOS which
      FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still
      be used by BIOS and the 0 value of the 32-bit firmware waking vector might
      trigger such failure.
      
      This patch enables the firmware waking vectors for both 32bit/64bit FACS
      tables in order to ensure we can exclude the cases that trigger the bugs
      caused by the root cause 2. The exclusion is split into 2 commits so that
      if it turns out not to be necessary, this single commit can be reverted
      without affecting the useful one. Lv Zheng, Bob Moore.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021
      Link: https://github.com/acpica/acpica/commit/368eb607
      Link: https://github.com/acpica/acpica/commit/70f62a80
      Link: https://github.com/acpica/acpica/commit/a04dbfa3
      Link: https://github.com/acpica/acpica/commit/ebd544edReported-and-tested-by: NOswald Buddenhagen <ossi@kde.org>
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f06147f9
    • L
      ACPICA: Tables: Enable both 32-bit and 64-bit FACS · c04e1fb4
      Lv Zheng 提交于
      ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486
      
      The following commit is reported to have broken s2ram on some platforms:
       Commit: 0249ed24
       ACPICA: Add option to favor 32-bit FADT addresses.
      The platform reports 2 FACS tables (which is not allowed by ACPI
      specification) and the new 32-bit address favor rule forces OSPMs to use
      the FACS table reported via FADT's X_FIRMWARE_CTRL field.
      
      The root cause of the reported bug might be one of the followings:
      1. BIOS may favor the 64-bit firmware waking vector address when the
         version of the FACS is greater than 0 and Linux currently only supports
         resuming from the real mode, so the 64-bit firmware waking vector has
         never been set and might be invalid to BIOS while the commit enables
         higher version FACS.
      2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the
         FADT while the commit doesn't set the firmware waking vector address of
         the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking
         vector address of the FACS reported by "X_FIRMWARE_CTRL".
      
      This patch excludes the cases that can trigger the bugs caused by the root
      cause 2.
      
      There is no handshaking mechanism can be used by OSPM to tell BIOS which
      FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still
      be used by BIOS and the 0 value of the 32-bit firmware waking vector might
      trigger such failure.
      
      This patch tries to favor 32bit FACS address in another way where both the
      FACS reported by "FIRMWARE_CTRL" and the FACS reported by "X_FIRMWARE_CTRL"
      are loaded so that further commit can set firmware waking vector in the
      both tables to ensure we can exclude the cases that trigger the bugs caused
      by the root cause 2. The exclusion is split into 2 commits as this commit
      is also useful for dumping more ACPI tables, it won't get reverted when
      such exclusion is no longer necessary. Lv Zheng.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021
      Link: https://github.com/acpica/acpica/commit/f7b86f35
      Cc: 3.14.1+ <stable@vger.kernel.org> # 3.14.1+
      Reported-and-tested-by: NOswald Buddenhagen <ossi@kde.org>
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c04e1fb4
  2. 05 2月, 2015 1 次提交
  3. 01 6月, 2014 1 次提交
    • L
      ACPICA: Tables: Add mechanism to control early table checksum verification. · 47d68c7f
      Lv Zheng 提交于
      It is reported that Linux x86 kernel cannot map large tables. The following
      large SSDT table on such platform fails to pass checksum verification and
      cannot be installed:
       ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL  S2600CP  00004000 INTL 20100331)
      
      It sounds strange that in the 64-bit virtual memory address space, we
      cannot map a single ACPI table to do checksum verification. 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.
      
      ACPICA originally only mapped table header for signature validation, and
      this header mapping is required by OSL override mechanism. There was no
      checksum verification because we could not map the whole table using this
      OSL. While the following ACPICA commit enforces checksum verification by
      mapping the whole table during Linux boot stage and it finally triggers
      this issue on some platforms:
       Commit: 86dfc6f3
       Subject: ACPICA: Tables: Fix table checksums verification before installation.
      
      Before doing further cleanups for the OSL table mapping and override
      implementation, this patch introduces an option for such OSPMs to
      temporarily discard the checksum verification feature. It then can be
      re-enabled easily when the ACPICA and the underlying OSL is ready.
      
      This patch also deletes a comment around the limitation of mappings because
      it is not correct. The limitation is not how many times we can map in the
      early stage, but the OSL mapping facility may not be suitable for mapping
      the ACPI tables and thus may complain us the size limitation.
      
      The acpi_tb_verify_table() is renamed to acpi_tb_verify_temp_table() due to the
      work around added, it now only applies to the table descriptor that hasn't
      been installed and cannot be used in other cases. Lv Zheng.
      Tested-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      47d68c7f
  4. 07 5月, 2014 2 次提交
    • L
      ACPICA: Tables: Remove old mechanism to validate if XSDT contains NULL entries. · 57429a40
      Lv Zheng 提交于
      With the NULL entry sanity check implemented, the XSDT validation is
      useless because:
      1. If XSDT contains NULL entries, it can be bypassed by the new sanity
         check mechanism;
      2. If RSDP contains a bad XSDT address, invoking XSDT validation will still
         lead to a kernel crash.
      
      This patch deletes the old XSDT validation solution and thus enables the
      new NULL entry sanity check solution.
      
      Note that if there are reports reporting regressions caused by the enabling
      of the new feature and disabling of the old feature, this commit should be
      bisected and reverted. Lv Zheng.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=73911
      References: https://bugs.archlinux.org/task/39811Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Reported-and-tested-by: NBruce Chiarelli <mano155@gmail.com>
      Reported-and-tested-by: NSpyros Stathopoulos <spystath@gmail.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      57429a40
    • L
      ACPICA: Tables: Add new mechanism to skip NULL entries in RSDT and XSDT. · 0f929fbf
      Lv Zheng 提交于
      It is reported that there are buggy BIOSes in the world: AMI uses an XSDT
      compiler for early BIOSes, this compiler will generate XSDT with a NULL
      entry.  The affected BIOS versions are "AMI BIOS F2-F4".
      
      Original solution on Linux is to use an alternative heathy root table
      instead of the ill one.  This commit is:
        Commit: 671cc68d
        Subject: ACPICA: Back port and refine validation of the XSDT root table.
      
      This is an example of such XSDT dumped from B85-HD3 (AMI F3 BIOS):
      [000h 0000   4]                    Signature : "XSDT"    [Extended System Description Table]
      [004h 0004   4]                 Table Length : 00000074
      [008h 0008   1]                     Revision : 01
      [009h 0009   1]                     Checksum : 18
      [00Ah 0010   6]                       Oem ID : "ALASKA"
      [010h 0016   8]                 Oem Table ID : "A M I"
      [018h 0024   4]                 Oem Revision : 01072009
      [01Ch 0028   4]              Asl Compiler ID : "AMI "
      [020h 0032   4]        Asl Compiler Revision : 00010013
      
      [024h 0036   8]       ACPI Table Address   0 : 00000000BA5F8180
      [02Ch 0044   8]       ACPI Table Address   1 : 00000000BA5F8290
      [034h 0052   8]       ACPI Table Address   2 : 00000000BA5F8308
      [03Ch 0060   8]       ACPI Table Address   3 : 00000000BA5F8848
      [044h 0068   8]       ACPI Table Address   4 : 00000000BA5F9320
      [04Ch 0076   8]       ACPI Table Address   5 : 00000000BA5F9360
      [054h 0084   8]       ACPI Table Address   6 : 00000000BA5F9398
      [05Ch 0092   8]       ACPI Table Address   7 : 00000000BA5F9708
      [064h d100   8]       ACPI Table Address   8 : 00000000BA5FC9A8
      [06Ch 0108   8]       ACPI Table Address   9 : 0000000000000000
      
      But according to the bug report, the XSDT in fact is not broken. In the
      above XSDT, ACPI Table Address 1-8 contains the same value as RSDT.  The
      differences can only be seen on the following 2 entries:
      1. The first entry points to a FADT whose Revision is 5 while the first
         entry in RSDT points to a FADT whose Revision is 2.
         The FADT dumped from the address indicated by the first entry of XSDT:
          FACP @ 0x00000000BA5F8180
            0000: 46 41 43 50 0C 01 00 00<05>4B 41 4C 41 53 4B 41  FACP.....KALASKA
            ...
         The FADT dumped from the address indicated by the first entry of RSDT:
          FACP @ 0x00000000BA5ED0F0
            0000: 46 41 43 50 84 00 00 00<02>A7 41 4C 41 53 4B 41  FACP......ALASKA
            ...
      2. The last entry is a NULL terminator.
      According to the test result, the Revision 5 FADT is accessible.  Thus the
      original solution turns out to be a work around that is preventing the
      higher revision tables to be used for such platforms (they are all x86-64
      platforms, and should use XSDT and higher revision FADT).
      
      This patch offers a new solution, where a sanity check is performed before
      installing a table address from XSDT. If the entry is NULL, it is simply
      discarded.
      
      Note that, this patch doesn't remove the original solution, so for Linux
      kernel, this commit is actually a no-op, but it allows acpidump to be
      working on such platforms. By doing so, we allow another easy revertable
      commit to enable this feature so that when that commit is reverted, the
      useful sanity check will not be affected. Lv Zheng.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=73911
      References: https://bugs.archlinux.org/task/39811Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Reported-and-tested-by: NBruce Chiarelli <mano155@gmail.com>
      Reported-and-tested-by: NSpyros Stathopoulos <spystath@gmail.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0f929fbf
  5. 06 5月, 2014 1 次提交
  6. 21 4月, 2014 7 次提交
    • B
      ACPICA: Table Manager: Misc cleanup and renames, no functional change. · ed6f1d44
      Bob Moore 提交于
      Some various cleanups and renames.
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ed6f1d44
    • L
      ACPICA: Tables: Add acpi_install_table() API for early table installation. · caf4a15c
      Lv Zheng 提交于
      This patch adds a new API - acpi_install_table(). OSPMs can use this API
      to install tables during early boot stage.  Lv Zheng.
      
      References: https://lkml.org/lkml/2014/2/28/372
      Cc: Thomas Renninger <trenn@suse.de>
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      [rjw: Subject]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      caf4a15c
    • L
      ACPICA: Tables: Cleanup ACPI_TABLE_ORIGIN_xxx flags. · 8a216d7f
      Lv Zheng 提交于
      This patch refines ACPI_TABLE_ORIGIN_xxx flags.  No functional changes.
      
      The previous commits have introduced the following internal APIs:
      1. acpi_tb_acquire_table: Acquire struct acpi_table_header according to
                             ACPI_TABLE_ORIGIN_xxx flags.
      2. acpi_tb_release_table: Release struct acpi_table_header according to
                             ACPI_TABLE_ORIGIN_xxx flags.
      3. acpi_tb_install_table: Make struct acpi_table_desc.Address not NULL according to
                             ACPI_TABLE_ORIGIN_xxx flags.
      4. acpi_tb_uninstall_table: Make struct acpi_table_desc.Address NULL according to
                               ACPI_TABLE_ORIGIN_xxx flags.
      5. acpi_tb_validate_table: Make struct acpi_table_desc.Pointer not NULL according to
                              ACPI_TABLE_ORIGIN_xxx flags.
      6. acpi_tb_invalidate_table: Make struct acpi_table_desc.Pointer NULL according to
                                ACPI_TABLE_ORIGIN_xxx flags.
      It thus detects that the ACPI_TABLE_ORIGIN_UNKNOWN is redundant to
      ACPI_TABLE_ORIGIN_OVERRIDE.
      
      The ACPI_TABLE_ORIGIN_xxTERN_VIRTUAL flags are named as VIRTUAL in order
      not to confuse with x86 logical address, this patch also renames all
      "logical override" into "virtual override".
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8a216d7f
    • L
      ACPICA: Tables: Fix table checksums verification before installation. · 86dfc6f3
      Lv Zheng 提交于
      The original table handling code does not always verify checksums before
      installing a table, this is because code to achieve this must be
      implemented here and there in the redundant code blocks.
      
      There are two stages during table initialization:
      1. "INSTALLED" after acpi_tb_install_table() and acpi_tb_override_table(),
         struct acpi_table_desc.Pointer is ensured to be NULL.  This can be safely used
         during OSPM's early boot stage.
      2. "VALIDATED" after acpi_tb_validate_table(), struct acpi_table_desc.Pointer is
         ensured to be not NULL.  This must not be used during OSPM's early boot
         stage.
      
      This patch changes acpi_tb_add_table() into an early boot safe API to reduce
      code redundancies by changing the table state that is returned by this
      function from "VALIDATED" to "INSTALLED".  Then the table verification
      code can be done in a single place.  Originally, the acpi_tb_add_table() can
      only be used by dynamic table loadings that are executed after early boot
      stage, it cannot be used by static table loadings that are executed in
      early boot stage as:
      1.  The address of the table is a virtual address either maintained by
          OSPMs who call acpi_load_table() or by ACPICA whenever "Load" or
          "LoadTable" opcodes are executed, while during early boot stage,
          physical address of the table should be used for table loading.
      2.  The API will ensure the state of the loaded table to be "VALIDATED"
          while during early boot stage, tables maintained by root table list
          should be kept as "INSTALLED".
      
      To achieve this:
      1. Rename acpi_tb_install_table() to acpi_tb_install_fixed_table() as it only
         applies to DSDT/FACS installation.  Rename acpi_tb_add_table() to
         acpi_tb_install_non_fixed_table() as it will be applied to the installation
         of the rest kinds of tables.
      2. Introduce acpi_tb_install_table(), acpi_tb_install_and_override_table to collect
         redudant code where their invocations actually have slight differences.
         1. acpi_tb_install_table() is used to fill an struct acpi_table_desc where the
            table length is known to the caller.
         2. acpi_tb_install_and_override_table() is used to perform necessary
            overriding before installation.
      3. Change a parameter of acpi_tb_install_non_fixed_table() from struct acpi_table_desc
         to acpi_physical_address to allow it to be invoked by static table
         loadings.  Also cleanup acpi_ex_load_op() and acpi_load_table() to accomodate
         to the parameter change.
      4. Invoke acpi_tb_install_non_fixed_table() for all table loadings other than
         DSDT/FACS in acpi_tb_parse_root_table() to improve code maintainability
         (logics are collected in the single function).  Also delete useless code
         from acpi_tb_parse_root_table().
      5. Remove all acpi_tb_validate_table() from acpi_tb_install_non_fixed_table() and
         acpi_tb_install_fixed_table() so that the table descriptor is kept in the
         state of "INSTALLED" but not "VALIDATED" after returning from these
         functions.
      6. Introduce temporary struct acpi_table_desc (new_table_desc/old_table_desc) into
         the functions to indicate a table descriptor that is not maintained by
         acpi_gbl_root_table_list. Introduce acpi_tb_acquire_temporal_table() and
         acpi_tb_release_temporal_table() to handle the use cases of such temporal
         tables.  They are only used for verified installation.
      7. Introduce acpi_tb_verify_table() to validate table and verify table
         checksum, also remove table checksum verification from
         acpi_tb_validate_table(). Invoke acpi_tb_validate_table() in the functions
         that will convert a table into "LOADED" state or invoke it from
         acpi_get_table_XXX() APIs. Invoke acpi_tb_verify_table() on temporary
         struct acpi_table_desc(s) that are going to be "INSTALLED".
      8. Change acpi_tb_override_table() logic so that a temporary struct acpi_table_desc
         will be overridden before installtion, this makes code simpler.
      
      After applying the patch, tables are always installed after being
      overridden and the table checksums are always verified before installation.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      [rjw: Subject]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      86dfc6f3
    • L
      ACPICA: Tables: Clean up split INSTALLED/VALIDATED table state logics. · 7f9fc99c
      Lv Zheng 提交于
      This patch is mainly a naming cleanup to clarify hidden logics, no
      functional changes.
      
      acpi_initialize_tables() is used by Linux to install table addresses for
      early boot steps.  During this stage, table addresses are mapped by
      early_ioremap() mechanism which is different from the runtime IO mappings.
      Thus it is not safe for ACPICA to keep mapped pointers in struct acpi_table_desc
      structure during this stage.
      
      In order to support this in ACPICA, table states are divided into
      1. "INSTALLED" (where struct acpi_table_desc.Pointer is always NULL) and
      2. "VALIDATED" (where struct acpi_table_desc.Pointer is always not NULL).
      During acpi_initialize_tables(), table state are ensured to be "INSTALLED"
      but not "VALIDATED".  This logic is ensured by the original code in very
      ambigious way.  For example, currently acpi_tb_delete_table() is invoked in
      some place to perform an uninstallation while it is invoked in other place
      to perform an invalidation.  They happen to work just because no one enters
      the penalty where the 2 behaviours are not equivalent.
      
      The naming cleanups are made in this patch:
      A. For installation and validation:
         There is code setting struct acpi_table_desc.Pointer first and delete it
         immediately to keep the descriptor's state as "INSTALLED" during the
         installation.  This patch implements this in more direct way.  After
         applying it, struct acpi_table_desc.Pointer will never be set in
         acpi_tb_install_table() and acpi_tb_override_table() as they are the only
         functions invoked during acpi_initialize_tables(). This is achieved by:
      1. Rename acpi_tb_verify_table() to acpi_tb_validate_table() to clarify this
         change.
      2. Rename acpi_tb_table_override() to acpi_tb_override_table() to keep nameing
         consistencies as other APIs (verb. Table).
      3. Stops setting struct acpi_table_desc.Pointer in acpi_tb_install_table() and
         acpi_tb_table_override().
      4. Introduce acpi_tb_acquire_table() to acquire the table pointer that is not
         maintained in the struct acpi_table_desc of the global root table list and
         rewrite acpi_tb_validate_table() using this new function to reduce
         redundancies.
      5. Replace the table pointer using the overridden table pointer in
         acpi_tb_add_table(). As acpi_tb_add_table() is not invoked during early boot
         stage, tables returned from this functions should be "VALIDATED".  As
         acpi_tb_override_table() is modified by this patch to return a "INSTALLED"
         but not "VALIDATED" descriptor, to keep acpi_tb_add_table() unchanged,
         struct acpi_table_desc.Pointer is filled in acpi_tb_add_table().
      B. For invalidation and uninstallation:
         The original code invalidate table by invoking acpi_tb_delete_table() here
         and there, but actually this function should only be used to uninstall
         tables.  This can work just because its invocations are equivalent to
         invalidation in some cases.
         This patch splits acpi_tb_delete_table() into acpi_tb_invalidate_table() and
         acpi_tb_uninstall_table() and cleans up the hidden logic using the new
         APIs.  This is achieved by:
      1. Rename acpi_tb_delete_table() to acpi_tb_uninstall_table() as it is mainly
         called before resetting struct acpi_table_desc.Address.  Thus the table
         descriptor is in "not INSTALLED" state.  This patch enforces this by
         setting struct acpi_table_desc.Address to NULL in this function.
      2. Introduce acpi_tb_invalidate_table() to be the reversal of
         acpi_tb_validate_table() and invoke it in acpi_tb_uninstall_table().
      3. Introduce acpi_tb_release_table() to release the table pointer that is not
         maintained in acpi_gbl_root_table_list and rewrite acpi_tb_invalidate_table()
         using this new function to reduce redundancies.
      
      After cleaning up, the maintainability of the internal APIs are also
      improved:
      1. acpi_tb_acquire_table: Acquire struct acpi_table_header according to
                             ACPI_TABLE_ORIGIN_xxx flags.
      2. acpi_tb_release_table: Release struct acpi_table_header according to
                             ACPI_TABLE_ORIGIN_xxx flags.
      3. acpi_tb_install_table: Make struct acpi_table_desc.Address not NULL according to
                             ACPI_TABLE_ORIGIN_xxx flags.
      4. acpi_tb_uninstall_table: Make struct acpi_table_desc.Address NULL according to
                               ACPI_TABLE_ORIGIN_xxx flags.
      5. acpi_tb_validate_table: Make struct acpi_table_desc.Pointer not NULL according to
                              ACPI_TABLE_ORIGIN_xxx flags.
      6. acpi_tb_invalidate_table: Make struct acpi_table_desc.Pointer NULL according to
                                ACPI_TABLE_ORIGIN_xxx flags.
      7. acpi_tb_override_table: Replace struct acpi_table_desc.Address and
                              struct acpi_table_desc.Flags.  It only happens in
                              "INSTALLED" state.
      
      The patch has been unit tested in acpi_exec by:
      1. Initializing;
      2. Executing exc_tbl ASLTS tests;
      3. Executing "Load" command.
      So that all original acpi_tb_install_table() and acpi_tb_override_table()
      invocations are covered.
      
      Known Issues:
      1. Cleanup acpi_tb_add_table() to Kill Code Redundancies
         Current implementation in acpi_tb_add_table() is not very clean, further
         patch can rewrite acpi_tb_add_table() with ordered acpi_tb_install_table(),
         acpi_tb_override_table() and acpi_tb_validate_table(). It is not done in this
         patch so that it is easy for the reviewers to understand the changes in
         this patch.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7f9fc99c
    • L
      ACPICA: Tables: Fix the issues in handling virtual addressed tables. · dc156adf
      Lv Zheng 提交于
      When table is overridden or reloaded, acpi_tb_delete_table() is called where
      struct acpi_table_desc.Pointer will be NULL.  It thus is impossible for virtual
      addressed tables to obtain the .Pointer again in acpi_tb_verify_table().
      
      This patch stores virtual table addresses  (ACPI_TABLE_ORIGIN_ALLOCATED,
      ACPI_TABLE_ORIGIN_UNKNOWN, ACPI_TABLE_ORIGIN_OVERRIDE) in the
      struct acpi_table_desc.Address field and refills the struct acpi_table_desc.Pointer
      using these addresses in acpi_tb_verify_table(). Note that if a table with
      ACPI_TABLE_ORIGIN_ALLOCATED set is actually freed, the .Address field
      should be invalidated and thus must be replaced with NULL to avoid wrong
      future validations occuring in acpi_tb_verify_table().
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      dc156adf
    • L
      ACPICA: Remove indent divergences to reduce maintenance overhead. · 5582982d
      Lv Zheng 提交于
      The divergences in the ACPICA files makes it difficult to maintain linuxize
      ACPICA table commits.  This patch reduces such divergences before applying
      table manager commits so that human interventions of patch rebasing can be
      reduced.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      [rjw: Subject]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5582982d
  7. 11 2月, 2014 1 次提交
  8. 08 1月, 2014 2 次提交
  9. 31 10月, 2013 2 次提交
  10. 16 6月, 2013 1 次提交
  11. 25 1月, 2013 1 次提交
  12. 10 1月, 2013 1 次提交
  13. 15 11月, 2012 1 次提交
  14. 17 7月, 2012 2 次提交
  15. 22 3月, 2012 2 次提交
  16. 17 1月, 2012 2 次提交
  17. 19 1月, 2011 1 次提交
  18. 06 5月, 2010 1 次提交
  19. 20 4月, 2010 5 次提交
  20. 23 1月, 2010 1 次提交
  21. 27 8月, 2009 1 次提交
  22. 27 3月, 2009 1 次提交