mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-18 02:04:05 +08:00
d5caf1cdc4
OSPMs like Linux trend to include all header files but leave empty stub
macros for a feature that is not configured during build.
For macros defined without other symbols referencesd it is safe to leave
them without protections.
By investigation, there are only the following internal/external
symbols referenced by the ACPICA macros:
1. C library symbols, including string, ctype, stdarg APIs. Since such
symbols are always accessbile in the kernel source tree, it is safe to
leave macros referencing them without protected for Linux.
2. ACPICA OSL symbols, such symbols are designed to be used only by ACPICA
internal APIs. And there are macros directly referencing mutex and
memory allocation OSL symbols. We need to examine the external usages
of such macros.
For macros referencing the mutex OSL symbols, fortunately, there is no
external user directly invoking such macros.
========================================================================
!! IMPORTANT !!
========================================================================
For macros referencing memory allocation OSL symbols -
1. 'free' - ACPI_FREE
2. 'alloc' - ACPI_ALLOCATE, ACPI_ALLOCATE_ZEROED, ACPI_ALLOCATE_BUFFER,
ACPI_ALLOCATE_LOCAL_BUFFER
there are external users directly invoking 'alloc' macros. And the more
complicated situation is the reversals of such macros are not ACPI_FREE
but acpi_os_free (or kfree) in Linux. Though we can define such macros
into no-op, we in fact cannot define their reversals into no-op.
This patch adds mechanism to protect ACPICA memory allocation APIs for
Linux so that acpi_os_free (or kfree) invoked in Linux can have a zero
address returned by 'alloc' macros to free. In this
way, acpi_os_free (or kfree) can be converted into no-op.
========================================================================
3. ACPI_OFFSET and other macros that would access structure members, we
need to check if such structure members are not accessible under a
specific configuration. Fortunately, currently Linux doesn't use such
structure members when CONFIG_ACPI is disabled.
This patch thus only adds mechanism useful for implementing stubs for
ACPICA provided macros - the configurability of memory allocation APIs.
This patch doesn't include code for Linux to use this new mechanism, thus
no functional changes. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
||
|---|---|---|
| .. | ||
| platform | ||
| acbuffer.h | ||
| acconfig.h | ||
| acexcep.h | ||
| acnames.h | ||
| acoutput.h | ||
| acpi_bus.h | ||
| acpi_drivers.h | ||
| acpi_io.h | ||
| acpi_numa.h | ||
| acpi.h | ||
| acpiosxf.h | ||
| acpixf.h | ||
| acrestyp.h | ||
| actbl1.h | ||
| actbl2.h | ||
| actbl3.h | ||
| actbl.h | ||
| actypes.h | ||
| apei.h | ||
| button.h | ||
| ghes.h | ||
| hed.h | ||
| pdc_intel.h | ||
| processor.h | ||
| reboot.h | ||
| video.h | ||