<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/include/acpi/acpi_io.h, branch v3.19-rc2</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>ACPI: Clean up acpi_os_map/unmap_memory() to eliminate __iomem.</title>
<updated>2014-05-27T16:13:08+00:00</updated>
<author>
<name>Lv Zheng</name>
<email>lv.zheng@intel.com</email>
</author>
<published>2014-05-20T07:39:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a238317ce8185519ed083e81e84260907fbbcf7f'/>
<id>a238317ce8185519ed083e81e84260907fbbcf7f</id>
<content type='text'>
ACPICA doesn't include protections around address space checking, Linux
build tests always complain increased sparse warnings around ACPICA
internal acpi_os_map/unmap_memory() invocations.  This patch tries to fix
this issue permanently.

There are 2 choices left for us to solve this issue:
 1. Add __iomem address space awareness into ACPICA.
 2. Remove sparse checker of __iomem from ACPICA source code.

This patch chooses solution 2, because:
 1.  Most of the acpi_os_map/unmap_memory() invocations are used for ACPICA.
     table mappings, which in fact are not IO addresses.
 2.  The only IO addresses usage is for "system memory space" mapping code in:
      drivers/acpi/acpica/exregion.c
      drivers/acpi/acpica/evrgnini.c
      drivers/acpi/acpica/exregion.c
    The mapped address is accessed in the handler of "system memory space"
    - acpi_ex_system_memory_space_handler().  This function in fact can be
    changed to invoke acpi_os_read/write_memory() so that __iomem can
    always be type-casted in the OSL layer.

According to the above investigation, we drew the following conclusion:
It is not a good idea to introduce __iomem address space awareness into
ACPICA mostly in order to protect non-IO addresses.

We can simply remove __iomem for acpi_os_map/unmap_memory() to remove
__iomem checker for ACPICA code. Then we need to enforce external usages
to invoke other APIs that are aware of __iomem address space.
The external usages are:
 drivers/acpi/apei/einj.c
 drivers/acpi/acpi_extlog.c
 drivers/char/tpm/tpm_acpi.c
 drivers/acpi/nvs.c

This patch thus performs cleanups in this way:
 1. Add acpi_os_map/unmap_iomem() to be invoked by non-ACPICA code.
 2. Remove __iomem from acpi_os_map/unmap_memory().

Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ACPICA doesn't include protections around address space checking, Linux
build tests always complain increased sparse warnings around ACPICA
internal acpi_os_map/unmap_memory() invocations.  This patch tries to fix
this issue permanently.

There are 2 choices left for us to solve this issue:
 1. Add __iomem address space awareness into ACPICA.
 2. Remove sparse checker of __iomem from ACPICA source code.

This patch chooses solution 2, because:
 1.  Most of the acpi_os_map/unmap_memory() invocations are used for ACPICA.
     table mappings, which in fact are not IO addresses.
 2.  The only IO addresses usage is for "system memory space" mapping code in:
      drivers/acpi/acpica/exregion.c
      drivers/acpi/acpica/evrgnini.c
      drivers/acpi/acpica/exregion.c
    The mapped address is accessed in the handler of "system memory space"
    - acpi_ex_system_memory_space_handler().  This function in fact can be
    changed to invoke acpi_os_read/write_memory() so that __iomem can
    always be type-casted in the OSL layer.

According to the above investigation, we drew the following conclusion:
It is not a good idea to introduce __iomem address space awareness into
ACPICA mostly in order to protect non-IO addresses.

We can simply remove __iomem for acpi_os_map/unmap_memory() to remove
__iomem checker for ACPICA code. Then we need to enforce external usages
to invoke other APIs that are aware of __iomem address space.
The external usages are:
 drivers/acpi/apei/einj.c
 drivers/acpi/acpi_extlog.c
 drivers/char/tpm/tpm_acpi.c
 drivers/acpi/nvs.c

This patch thus performs cleanups in this way:
 1. Add acpi_os_map/unmap_iomem() to be invoked by non-ACPICA code.
 2. Remove __iomem from acpi_os_map/unmap_memory().

Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / i915: Fix incorrect &lt;acpi/acpi.h&gt; inclusions via &lt;linux/acpi_io.h&gt;</title>
<updated>2013-12-07T00:24:33+00:00</updated>
<author>
<name>Lv Zheng</name>
<email>lv.zheng@intel.com</email>
</author>
<published>2013-12-06T08:52:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=27d50c82714f6477ac690034b37d202f76eb4f70'/>
<id>27d50c82714f6477ac690034b37d202f76eb4f70</id>
<content type='text'>
To avoid build problems and breaking dependencies between ACPI header
files, &lt;acpi/acpi.h&gt; should not be included directly by code outside
of the ACPI core subsystem.  However, that is possible if
&lt;linux/acpi_io.h&gt; is included, because that file contains
a direct inclusion of &lt;acpi/acpi.h&gt;.

For this reason, remove the direct &lt;acpi/acpi.h&gt; inclusion from
&lt;linux/acpi_io.h&gt;, move that file from include/linux/ to include/acpi/
and make &lt;linux/acpi.h&gt; include it for CONFIG_ACPI set along with the
other ACPI header files.  Accordingly, Remove the inclusions of
&lt;linux/acpi_io.h&gt; from everywhere.

Of course, that causes the contents of the new &lt;acpi/acpi_io.h&gt; file
to be available for CONFIG_ACPI set only, so intel_opregion.o that
depends on it should also depend on CONFIG_ACPI (and it really should
not be compiled for CONFIG_ACPI unset anyway).

References: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf
Cc: Matthew Garrett &lt;mjg59@srcf.ucam.org&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To avoid build problems and breaking dependencies between ACPI header
files, &lt;acpi/acpi.h&gt; should not be included directly by code outside
of the ACPI core subsystem.  However, that is possible if
&lt;linux/acpi_io.h&gt; is included, because that file contains
a direct inclusion of &lt;acpi/acpi.h&gt;.

For this reason, remove the direct &lt;acpi/acpi.h&gt; inclusion from
&lt;linux/acpi_io.h&gt;, move that file from include/linux/ to include/acpi/
and make &lt;linux/acpi.h&gt; include it for CONFIG_ACPI set along with the
other ACPI header files.  Accordingly, Remove the inclusions of
&lt;linux/acpi_io.h&gt; from everywhere.

Of course, that causes the contents of the new &lt;acpi/acpi_io.h&gt; file
to be available for CONFIG_ACPI set only, so intel_opregion.o that
depends on it should also depend on CONFIG_ACPI (and it really should
not be compiled for CONFIG_ACPI unset anyway).

References: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf
Cc: Matthew Garrett &lt;mjg59@srcf.ucam.org&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
