| Age | Commit message (Collapse) | Author |
|---|
|
* acpi-video:
ACPI: move models with win8 brightness problems from win8 blacklist to use_native_backlight
ACPI / video: Fix backlight taking 2 steps on a brightness up/down keypress
* acpi-hotplug:
ACPI / hotplug / PCI: Fix sparse non static symbol warning
ACPI / hotplug: Simplify acpi_set_hp_context()
ACPI / hotplug / PCI: Eliminate acpiphp_dev_to_bridge()
|
|
* acpi-pnp:
ACPI / PNP: Use ACPI_COMPANION() instead of ACPI_HANDLE()
ACPI / PNP: do ACPI binding directly
* acpi-pci:
ACPI / PCI: Use ACPI_COMPANION() instead of ACPI_HANDLE()
|
|
* acpi-pm:
ACPI / PM: Use ACPI_COMPANION() instead of ACPI_HANDLE()
ACPI / PM: Always enable wakeup GPEs when enabling device wakeup
ACPI / PM: Revork the handling of ACPI device wakeup notifications
PM: Create PM workqueue if runtime PM is not configured too
* acpi-sleep:
ACPI / sleep: Do not save NVS for new machines to accelerate S3
* acpi-button:
ACPI / button: Do not propagate wakeup-from-suspend events
|
|
* acpi-gpe:
ACPI / scan: No implicit wake notification for buttons
|
|
* acpi-config:
ACPI / processor: Introduce ARCH_MIGHT_HAVE_ACPI_PDC
ACPI: Don't use acpi_lapic in ACPI core code
ACPI: add config for BIOS table scan
|
|
* acpi-headers:
ACPI: Add support to force header inclusion rules for <acpi/acpi.h>.
ACPI / SFI: Fix wrong <acpi/acpi.h> inclusion in SFI/ACPI wrapper - table definitions.
ACPICA: Linux: Allow ACPICA inclusion for CONFIG_ACPI=n builds.
ACPICA: Linux: Add support to exclude <asm/acenv.h> inclusion.
ACPICA: Linux: Add stub implementation of ACPICA 64-bit mathematics.
ACPICA: Linux: Add stub support for Linux specific variables and functions.
|
|
* acpica: (30 commits)
ACPICA: Add new GPE public interface - acpi_mark_gpe_for_wake.
ACPICA: GPEs: Do not allow enable for GPEs that have no handler(s).
ACPICA: Fix a regression for deletion of Alias() objects.
ACPICA: Update version to 20140627
ACPICA: Tables: Merge DMAR table structure updates
ACPICA: Hardware: back port of a recursive locking fix
ACPICA: utprint/oslibcfs: cleanup - no functional change
ACPICA: Executer: Fix trivial issues in acpi_get_serial_access_bytes()
ACPICA: OSL: Update acpidump to reduce source code differences
ACPICA: acpidump: Reduce freopen() invocations to improve portability
ACPICA: acpidump: Replace file IOs with new APIs to improve portability
ACPICA: acpidump: Remove exit() from generic layer to improve portability
ACPICA: acpidump: Add memory/string OSL usage to improve portability
ACPICA: Common: Enhance acpi_getopt() to improve portability
ACPICA: Common: Enhance cm_get_file_size() to improve portability
ACPICA: Application: Enhance ACPI_USAGE_xxx/ACPI_OPTION with acpi_os_printf() to improve portability
ACPICA: Utilities: Introduce acpi_log_error() to improve portability
ACPICA: Utilities: Add formatted printing APIs
ACPICA: OSL: Add portable file IO to improve portability
ACPICA: OSL: Clean up acpi_os_printf()/acpi_os_vprintf() stubs
...
|
|
NVS region is saved and restored unconditionally for machines without
nvs_nosave quirk during S3. Tested some new machines and the operation
is not necessary. Saving NVS region also affects S2RAM speed. The time of
NVS saving and restoring depends on the size of NVS region and it consumes
7~10ms normally.
This patch is to make machines produced from 2012 to now not saving NVS region
to accelerate S3.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The ACPI device enumeration code in Linux assumes that buttons always
are wakeup devices, so it calls acpi_setup_gpe_for_wake() for them
which leads to undesirable side effects. Namely, that function sets
up implicit device wake notification mechanism for a given GPE if
there is no handler method in the ACPI namespace, which from the
ACPICA's perspective means that there always is a way to handle
that GPE if enabled. However, we don't handle wake notify events
for buttons, so if there are no handler methods for their GPEs in
the namespace, enabling a button GPE at run time leads to a GPE
storm in some cases (the GPE triggers, ACPICA carries out the
implicit wake notification for it which isn't handled, so the
GPE triggers again and so on).
To prevent that from happening use acpi_mark_gpe_for_wake()
instead of acpi_setup_gpe_for_wake() for buttons which will cause
ACPICA to only enable button GPEs if there are handler methods for
the in the namespace.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
|
|
ACPICA commit c49dbfed2bc069d0038ea7e1294409bfde7c2c8c
Some potential callers of acpi_setup_gpe_for_wake may know in advance that
there won't be any notify handlers installed for device wake notifications
from the given GPE (one example is a button GPE in Linux). For these cases,
acpi_mark_gpe_for_wake should be used instead of acpi_setup_gpe_for_wake.
This will set the ACPI_GPE_CAN_WAKE flag for the GPE without trying to
setup implicit wake notification for it (since there's no handler method).
Rafael Wysocki.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
|
|
ACPICA commit 23b5a8542283af28c3a3a4e3f81096d6e2569faa
There is no point in enabling a GPE that has no handler or
GPE method. At worst, it can cause GPE floods.
Rafael Wysocki.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
|
|
As there is only CONFIG_ACPI=n processing in the <linux/acpi.h>, it is not
safe to include <acpi/acpi.h> directly for source out of Linux ACPI
subsystems.
This patch adds error messaging to warn developers of such wrong
inclusions.
In order not to be bisected and reverted as a wrong commit, warning
messages are carefully split into a seperate patch other than the wrong
inclusion cleanups.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The ACPI_HANDLE() macro evaluates ACPI_COMPANION() internally to
return the handle of the device's ACPI companion, so it is much
more straightforward and efficient to use ACPI_COMPANION()
directly to obtain the device's ACPI companion object instead of
using ACPI_HANDLE() and acpi_bus_get_device() on the returned
handle for the same thing.
Do that in three places in the ACPI device PM code.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Wakeup GPEs are currently only enabled when setting up devices for
remote wakeup at run time. During system-wide transitions they are
enabled by ACPICA at the very last stage of suspend (before asking
the BIOS to take over). Of course, that only works for system
sleep states supported by ACPI, so in particular it doesn't work
for the "freeze" sleep state.
For this reason, modify the ACPI core device PM code to enable wakeup
GPEs for devices when setting them up for wakeup regardless of whether
that is remote wakeup at runtime or system wakeup. That allows the
same device wakeup setup routine to be used for both runtime PM and
system-wide PM and makes it possible to reduce code size quite a bit.
This make ACPI-based PCI Wake-on-LAN work with the "freeze" sleep
state on my venerable Toshiba Portege R500 and should help other
systems too.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Since ACPI wakeup GPEs are going to be enabled during system suspend
as well as for runtime wakeup by a subsequent patch and the same
notify handlers will be used in both cases, rework the ACPI device
wakeup notification framework so that the part specific to physical
devices is always run asynchronously from the PM workqueue. This
prevents runtime resume callbacks for those devices from being
run during system suspend and resume which may not be appropriate,
among other things.
Also make ACPI device wakeup notification handling a bit more robust
agaist subsequent removal of ACPI device objects, whould that ever
happen, and create a wakeup source object for each ACPI device
configured for wakeup so that wakeup notifications for those
devices can wake up the system from the "freeze" sleep state.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
During system suspend mark ACPI buttons (other than the lid) as
"suspended" and if in that state, report wakeup events on button
events, but do not propagate those events up the stack.
This prevents systems from being turned off after a button-triggered
wakeup from the "freeze" sleep state.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77611
Tested-on: Acer Aspire S5, Toshiba Portege R500
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
GHES currently maps two pages with atomic_ioremap. From now
on, NMI is architectural depended so there is no need to allocate
an NMI page for platforms without NMI support.
To make it possible to not use a second page, swap the existing
page order so that the IRQ context page is first, and the optional
NMI context page is second. Then, use HAVE_ACPI_APEI_NMI to decide
how many pages are to be allocated.
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
Currently APEI depends on x86 architecture. It is because of NMI hardware
error notification of GHES which is currently supported by x86 only.
However, many other APEI features can be still used perfectly by other
architectures.
This commit adds two symbols:
1. HAVE_ACPI_APEI for those archs which support APEI.
2. HAVE_ACPI_APEI_NMI which is used for NMI code isolation in ghes.c
file. NMI related data and functions are grouped so they can be wrapped
inside one #ifdef section. Appropriate function stubs are provided for
!NMI case.
Note there is no functional changes for x86 due to hard selected
HAVE_ACPI_APEI and HAVE_ACPI_APEI_NMI symbols.
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
This commit abstracts MCE calls and provides weak corresponding default
implementation for those architectures which do not need arch specific
actions. Each platform willing to do additional architectural actions
should provides desired function definition. It allows us to avoid wrap
code into #ifdef in generic code and prevent new platform from introducing
dummy stub function too.
Initially, there are two APEI arch-specific calls:
- arch_apei_enable_cmcff()
- arch_apei_report_mem_error()
Both interact with MCE driver for X86 architecture.
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
The use of _PDC is deprecated in ACPI 3.0 in favor of _OSC,
as ARM platform is supported only in ACPI 5.0 or higher version,
_PDC will not be used in ARM platform, so make Make _PDC only for
platforms with Intel CPUs.
Introduce ARCH_MIGHT_HAVE_ACPI_PDC and move _PDC related code in
ACPI processor driver into a single file processor_pdc.c, make x86
and ia64 select it when ACPI is enabled.
This patch also use pr_* to replace printk to fix the checkpatch
warning and factor acpi_processor_alloc_pdc() a little bit to
avoid duplicate pr_err() code.
Suggested-by: Robert Richter <rric@kernel.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Now ARM64 support is being added to ACPI so architecture specific
values can not be used in core ACPI code.
Following on the patch "ACPI / processor: Check if LAPIC is present
during initialization" which uses acpi_lapic in acpi_processor.c,
on ARM64 platform, GIC is used instead of local APIC, so acpi_lapic
is not a suitable value for ARM64.
What is actually important at this point is if there is/are CPU
entry/entries (Local APIC/SAPIC, GICC) in MADT, so introduce
acpi_has_cpu_in_madt() to be arch specific and generic.
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
With the addition of ARM64 that does not have a traditional BIOS to
scan, add a config option which is selected on x86 (ia64 doesn't need
it either, it is EFI/UEFI based system) to do the traditional BIOS
scanning for tables.
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
use_native_backlight
When the windows8 related backlight problems became evident, 2 approaches
were follow in parallel, one was to stop claiming to be windows 8 / 2012,
the other was to tell acpi_video to stop registering a backlight driver.
I've read all the threads and it seems that which approach ended up being
applied to which model laptop was never really a concious decision (AFAIK):
https://bugzilla.kernel.org/show_bug.cgi?id=51231
https://bugzilla.kernel.org/show_bug.cgi?id=60682
So lets move all the models which are only on the win8 blacklist because of
brightness issues to the use_native_backlight list, which is the smaller
hammer to use to solve the backlight issues.
Making this change is esp. attractive now that 3.16 has
video.use_native_brightness=1 by default. If that new default does not get
reverted because of regressions, then we can drop all the models
with a use_native_backlight quirk, greatly reducing the number of models we've
a quirk for.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=51231
Link: https://bugzilla.kernel.org/show_bug.cgi?id=60682
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
In various scenarious userspace will respond to brightness up/down keypresses
by increasing/decreasing the backlight brightness itself. If the kernel then
also changes the brightness this results in the brightness having changed 2
steps for a single keypress which is undesirable. See e.g. :
https://bugs.launchpad.net/gnome-settings-daemon/+bug/527157
http://askubuntu.com/questions/173921/why-does-my-thinkpad-brightness-control-skip-steps
This commit delays responding to brightness up/down keypresses by 100 ms and
if userspace in that time responds by changing the backlight itself, cancels
the kernels own handling of these keypresses, fixing the 2 steps issue.
Link: http://marc.info/?l=linux-kernel&m=140535721100839&w=2
[hdegoede@redhat.com: Move the delayed_work struct into struct
acpi_video_device instead of having it as a global]
[hdegoede@redhat.com: Keep brightness_switch_enabled as a boolean and always
delay the keypress handling]
Tested-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There are global variables and functions not upstreamed to the ACPICA code
base. Such symbols still can be referenced by external users as they are
listed in the acpixf.h. This patch uses ACPI_GLOBAL and
ACPI_EXTERNAL_RETURN_STATUS mechanism to add stub support for such symbols.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
As reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1025690
This is yet another model which needs this quirk.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1025690
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Since all of the acpi_set_hp_context() callers pass at least one NULL
function pointer and one caller passes NULL function pointers only
to it, drop function pointer arguments from acpi_set_hp_context()
and make the callers initialize the function pointers in struct
acpi_hotplug_context by themselves before passing it to
acpi_set_hp_context().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
This reverts commit 886129a8eebeb (ACPI / video: change acpi-video
brightness_switch_enabled default to 0) as it is reported to cause
problems to happen.
Fixes: 886129a8eebeb (ACPI / video: change acpi-video brightness_switch_enabled default to 0)
Link: http://marc.info/?l=linux-acpi&m=140534286826819&w=2
Reported by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Report extended error information ("extlog") using
a trace/event. Provide a mechanism for a smart
daemon collecting this information to tell the kernel
to skip logging corrected errors to the console.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
* acpi-video:
ACPI / video: Add Acer TravelMate B113 to native backlight blacklist
ACPI / video: Add Dell Inspiron 5737 to the blacklist
ACPI / i915: ignore firmware requests for backlight change
|
|
* acpi-ec:
ACPI / EC: Free saved_ec on error exit path
ACPI / EC: Add detailed fields debugging support of EC_SC(R).
ACPI / EC: Update revision due to recent changes
ACPI / EC: Fix race condition in ec_transaction_completed()
ACPI / EC: Remove duplicated ec_wait_ibf0() waiter
ACPI / EC: Add asynchronous command byte write support
ACPI / EC: Avoid race condition related to advance_transaction()
|
|
* acpi-resources:
ACPI / resources: only reject zero length resources based at address zero
* acpi-ac:
Revert "ACPI / AC: Remove AC's proc directory."
* acpi-scan:
ACPI / PNP: add soc_button_array device ID to PNP IDs list
* acpi-battery:
ACPI / battery: fix wrong value of capacity_now reported when fully charged
ACPI / battery: Retry to get battery information if failed during probing
|
|
Fixes a regression introduced by commit e23d9b829754 (ACPICA:
Namespace: Properly null terminate objects detached from a namespace
node)
In the case of Alias namespace nodes, the node simply points to the aliased
node via the Object field; thus we cannot assume that the object is an
operand object.
Fixes: e23d9b829754 (ACPICA: Namespace: Properly null terminate objects detached from a namespace node)
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The soc_button_array PNP driver was introduced in 3.15.
But in commit eec15edbb0e1 (ACPI / PNP: use device ID list for
PNPACPI device enumeration), when reworking the PNPACPI device
enumeration, we missed the soc_button_array device ID.
This results in a regression in 3.16-rc1 that soc_button_array
pnp device fails to be enumerated.
Fix the problem by adding soc_button_array device ID into the
acpi_pnp scan handler's ID list.
Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch is a back port result of the following Linux commit:
Commit: f7f71cfbf0c276ee3d8d856d0f35a41aed997fa4
Author: Rakib Mullick <rakib.mullick@gmail.com>
Subject: ACPI: Fix possible recursive locking in hwregs.c
As a result of different coding style rules, the back ported code generates
source code differences between the Linux kernel and the ACPICA upstream.
This patch reduces such source code differences.
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>
|
|
Some cleanup and comment update.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch fixes trivial issues in acpi_get_serial_access_bytes(), no real
functional bugs. 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>
|
|
This patch reduces the requirement of invoking freopen() in acpidump in order
to reduce the porting effort of acpidump.
This patch achieves this by turning all acpi_os_printf(stdout) into
acpi_ut_file_printf(gbl_output_file). 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>
|
|
This patch enhances acpi_getopt() by converting the standard C library
invocations into portable ACPI string APIs and acpi_log_error() to improve
portability. 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>
|
|
This patch uses abstract file IO and acpi_log_error() APIs to enhance
cm_get_file_size() so that applications that invoke this API could have
portability improved.
With actual references added to abstract file IO and acpi_log_error(), the
applications need to link oslibcfs.o, utdebug.o, utexcep.o, utmath.o,
utprint.o and utxferror.o.
It is also required to add acpi_os_initialize() invocations if an
application starts to use acpi_log_error().
acpidump has already invoked acpi_os_initialize() in this way. 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>
|
|
acpi_os_printf() to improve portability
This patch enhances ACPI_USAGE_xxx/ACPI_OPTION macros to use portable
acpi_os_printf() so that usage functions for applications no longer rely on
the printf() API.
To use acpi_os_printf() exported by osunixxf.c as a replacement of
printf(), applications need to initialize acpi_gbl_output_file to stdout
and initialize acpi_gbl_db_output_flags to ACPI_DB_CONSOLE_OUTPUT. The
latter is automatically done by ACPI_INIT_GLOBAL(), applications need to
link utglobal.o to utilize this mechanism. For GCC, assigning stdout to
acpi_gbl_output_file using ACPI_INIT_GLOBAL() is not possible as stdout is
not a constant in GCC environment. As an alternative solution, stdout
assignment has been put into acpi_os_initialize(). Thus
acpi_os_initialize() need to be invoked very early by the applications to
initialize the default output of acpi_os_printf() to keep behavior
consistency.
acpidump has already invoked acpi_os_initialize() in this way. 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>
|
|
Invocations like fprintf(stderr) and perror() are not portable, this patch
introduces acpi_log_error() as a replacement, it is implemented using new
portable API - acpi_ut_file_vprintf().
Note that though acpi_os_initialize() need to be invoked prior than using
this new API, since no users are introduced in this patch, such invocations
are not added for applications that link utprint.c in this patch. Futher
patches that introduce users of acpi_log_error() should take care of this.
This patch is only useful for ACPICA applications, most of which are not
shipped in the Linux kernel.
Note that follow-up commits will update acpidump to use this new API to
improve portability. 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>
|
|
This patch introduces formatted printing APIs to handle ACPICA specific
formatted print requirements. Currently only specific OSPMs will use this
customized printing support, Linux kernel doesn't use these APIs at this
time. It will be enabled for Linux kernel resident ACPICA after being well
tested. So currently this patch is a no-op.
The specific formatted printing APIs are useful to ACPICA as:
1. Some portable applications do not link standard C library, so they
cannot use standard formatted print APIs directly.
2. Platform specific printing format may differ and thus not portable, for
example, u64 is %ull for Linux kernel and is %uI64 for some MSVC
versions.
3. Platform specific printing format may conflict with ACPICA's usages
while it is not possible for ACPICA developers to test their code for
all platforms. For example, developers may generate %pRxxx while Linux
kernel treats %pR as structured resource printing and decodes variable
argument as a "struct resource" pointer.
This patch solves above issues by introducing the new APIs.
Note that users of such APIs are not introduced in this patch. Users of
acpi_os_file_vprintf()/acpi_ut_file_printf() need to invoke acpi_os_initialize(),
this should be taken care by the further patches where such users are
introduced. 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>
|
|
This patch is mainly for acpidump where there are redundant
acpi_os_printf()/acpi_os_vprintf() stubs implemented. This patch cleans up such
specific implementation by linking acpidump to osunixxf.c/oswinxf.c.
To make acpi_os_printf() exported by osunixxf.c/oswinxf.c to behave as the
old acpidump specific ones, applications need to:
1. Initialize acpi_gbl_db_output_flags to ACPI_DB_CONSOLE_OUTPUT.
This is automatically done by ACPI_INIT_GLOBAL(), applications need to
link utglobal.o to utilize this mechanism.
2. Initialize acpi_gbl_output_file to stdout.
For GCC, assigning stdout to acpi_gbl_output_file using ACPI_INIT_GLOBAL()
is not possible as stdout is not a constant in GCC environment. As an
alternative solution, stdout assignment is put into acpi_os_initialize().
Thus acpi_os_initialize() need to be invoked very early by the
applications to initialize the default output of acpi_os_printf().
This patch also releases osunixxf.c to the Linux kernel. 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>
|
|
acpi_ut_init_global() from utglobal.c to utinit.c
The utglobal.c is used to define and initialize global variables. It makes
sense if just adding utglobal.o to applications that are using such
variables. But acpi_ut_init_globals() is preventing us from doing so as
this initialization function references other components' initializations
code, which leads to the requirement that many files should also get linked
if one wants to link utglobal.o.
It is possible to just move acpi_ut_init_global() to utinit.c for
applications that require this function to link.
By linking utglobal.o, we can stop defining DEFINE_ACPI_GLOBALS for
applications (currently only acpidump is affected). 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>
|
|
node
Fixes a bug exposed by an ACPICA unit test around the
acpi_attach_data()/acpi_detach_data() APIs where the failure to null
terminate a detached object led to the creation of a circular linked list
(and infinite looping) when the object is reattached.
Reported in acpica bugzilla #1063
Link: https://bugs.acpica.org/show_bug.cgi?id=1063
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Implement proper RSDP validation in acpi_ut_read_table(). Prevents a segmentation
fault that can occur if a user passes the wrong file to iasl.
This patch is only useful for iasl, which is not shipped in the Linux
kernel.
After the new table reading utility functions are well tested, acpidump can
also switch to use the generic acpi_ut_read_table_xxx() APIs. Currently
this patch is no-op as acpidump does not link to the new APIs.
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
After the new table reading utility functions are well tested, acpidump can
also switch to use the generic acpi_ut_read_table_xxx() APIs. Currently
this patch is no-op as acpidump does not link to the new APIs.
This patch is only useful for ACPICA applications, most of which are not
shipped in the Linux kernel.
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>
|
|
An error was found in the ACPICA provided non-native ACPI_IS_PRINT() causing the
following difference with the native isprint() implementation:
The GNU libc isprint('\n') test result:
isprint(0x20) is FALSE
The Linux kernel isprint('\n') test result:
ACPI: isprint(0x20) is FALSE
The _acpi_ctype isprint('\n') test result:
isprint(0x20) is TRUE
The ACPI_IS_PRINT() macro generated for _acpi_ctype is wrong. It should use
_ACPI_XS instead of _ACPI_SP. _ACPI_XS is white space only. Other space
characters should be non printable.
This patch fixes this issue. For OSPMs that are using native standard
isprint() implementations, this patch is a no-op. 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>
|
