Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 15 6月, 2016 1 次提交
  3. 02 6月, 2016 1 次提交
    • L
      ACPICA / Hardware: Fix old register check in acpi_hw_get_access_bit_width() · 7f9bef9d
      由 Lv Zheng 提交于 
      The address check in acpi_hw_get_access_bit_width() should be byte width
based, not bit width based. This patch fixes this mistake.

For those who want to review acpi_hw_access_bit_width(), here is the
concerns and the design details of the function:

It is supposed that the GAS Address field should be aligned to the byte
width indicated by the GAS AccessSize field. Similarly, for the old non
GAS register, it is supposed that its Address should be aligned to its
Length.

For the "AccessSize = 0 (meaning ANY)" case, we try to return the maximum
instruction width (64 for MMIO or 32 for PIO) or the user expected access
bit width (64 for acpi_read()/acpi_write() or 32 for acpi_hw_read()/
acpi_hw_write()) and it is supposed that the GAS Address field should
always be aligned to the maximum expected access bit width (otherwise it
can't be accessed using ANY access bit width).

The problem is in acpi_tb_init_generic_address(), where the non GAS
register's Length is converted into the GAS BitWidth field, its Address is
converted into the GAS Address field, and the GAS AccessSize field is left
0 but most of the registers actually cannot be accessed using "ANY"
accesses.

As a conclusion, when AccessSize = 0 (ANY), the Address should either be
aligned to the BitWidth (wrong conversion) or aligned to 32 for PIO or 64
for MMIO (real GAS). Since currently, max_bit_width is 32, then:
1. BitWidth for the wrong conversion is 8,16,32; and
2. The Address of the real GAS should always be aligned to 8,16,32.
The address alignment check to exclude false matched real GAS is not
necessary. Thus this patch fixes the issue by removing the address
alignment check.

On the other hand, we in fact could use a simpler check of
"reg->bit_width < max_bit_width" to exclude the "BitWidth=64 PIO" case that
may be issued from acpi_read()/acpi_write() in the future.

Fixes: b314a172 (ACPICA: Hardware: Add optimized access bit width support)
Reported-and-tested-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: NMike Marshall <hubcap@omnibond.com>
Suggested-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7f9bef9d
  5. 05 5月, 2016 3 次提交
  7. 05 4月, 2016 1 次提交
  9. 16 1月, 2016 1 次提交
  11. 05 2月, 2015 1 次提交
  13. 08 7月, 2014 1 次提交
  15. 11 2月, 2014 1 次提交
  17. 31 10月, 2013 1 次提交
  19. 16 6月, 2013 1 次提交
  21. 25 1月, 2013 1 次提交
  23. 10 1月, 2013 3 次提交
    • L
      ACPICA: Cleanup indentation to reduce differences between Linux and ACPICA. · 3e8214e5
      由 Lv Zheng 提交于 
      This is a cosmetic patch only. Comparison of the resulting binary showed
only line number differences.

This patch does not affect the generation of the Linux binary.
This patch decreases 210 lines of 20121018 divergence.diff.

The ACPICA source codes uses a totally different indentation style from the
Linux to be compatible with other users (operating systems or BIOS).

Indentation differences are critical to the release automation. There are
two causes related to the "indentation" that are affecting the release
automation:
1. The ACPICA -> Linux release process is:
     ACPICA source -- acpisrc - hierarchy - indent ->
     linuxized ACPICA source -- diff ->
     linuxized ACPICA patch (x) -- human intervention ->
     linuxized ACPICA patch (o)
     Where
       'x' means "cannot be directly applied to the Linux"
       'o' means "can be directly applied to the Linux"
   Different "indent" version or "indent" options used in the "indent"
   step will lead to different divergences.
   The version of "indent" used for the current release process is:
     GNU indent 2.2.11
   The options of "indent" used for the current release process is:
     -npro -kr -i8 -ts8 -sob -l80 -ss -ncs
2. Manual indentation prettifying work in the Linux side will also harm the
   automatically generated linuxized ACPICA patches, making them impossible
   to apply directly.

This patch fixes source code differences caused by the two causes so that
the "human intervention" can be reduced in the future.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3e8214e5
    • L
      ACPICA: Cleanup source to reduce differences between Linux and ACPICA. · 739dcbb9
      由 Lv Zheng 提交于 
      This is a cosmetic patch only. Comparison of the resulting binary showed
only line number differences.

This patch does not affect the generation of the Linux binary.
This patch decreases 389 lines of 20121018 divergence.diff.

This patch reduces source code diff caused by the simple code maintenance
work:
1. Deletion of the unused include files.
2. Deletion of the deprecated codes blocks.
3. Repositioning of the code blocks.
4. Replacing the values with the well defined macros.
5. Replacing the types with the equivalent types.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      739dcbb9
    • L
      ACPICA: Cleanup updated comments. · 75c8044f
      由 Lv Zheng 提交于 
      This is a cosmetic patch only. Comparison of the resulting binary showed
only line number differences.

This patch does not affect the generation of the Linux binary.
This patch decreases 558 lines of 20121018 divergence.diff.

This patch reduces the source code diff between Linux and ACPICA by
cleaning the comments that already have been updated in ACPICA.

There is no extra indentation done in this patch. Even the empty line
deletions and insertions are also splitted into another cleanup patch so
that this patch can be easily reviewed, and the binary differences can be
held to a lowest level.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      75c8044f
  25. 15 11月, 2012 1 次提交
  27. 17 7月, 2012 1 次提交
  29. 22 3月, 2012 2 次提交
  31. 17 1月, 2012 1 次提交
  33. 07 11月, 2011 1 次提交
  35. 19 1月, 2011 1 次提交
  37. 20 4月, 2010 1 次提交
  39. 23 1月, 2010 1 次提交
  41. 27 8月, 2009 1 次提交
  43. 27 5月, 2009 1 次提交
  45. 28 3月, 2009 4 次提交
  47. 27 3月, 2009 5 次提交
  49. 09 1月, 2009 2 次提交
  51. 31 12月, 2008 2 次提交