Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 4 年多

通知 15
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 05 5月, 2016 4 次提交
  3. 10 3月, 2016 2 次提交
  5. 03 1月, 2016 1 次提交
  7. 15 12月, 2015 2 次提交
  9. 26 10月, 2015 2 次提交
  11. 22 10月, 2015 1 次提交
    • L
      ACPI: Enable build of AML interpreter debugger · 4d946f79
      由 Lv Zheng 提交于 
      This patch enables ACPICA debugger files using a configurable
CONFIG_ACPI_DEBUGGER configuration item. Those debugger related code that
was originally masked as ACPI_FUTURE_USAGE now gets unmasked.

Necessary OSL stubs are also added in this patch:
1. acpi_os_readable(): This should be arch specific in Linux, while this
    patch doesn't introduce real implementation and a complex mechanism to
    allow architecture specific acpi_os_readable() to be implemented to
    validate the address. It may be done by future commits.
2. acpi_os_get_line(): This is used to obtain debugger command input. This
    patch only introduces a simple KDB concept example in it and the
    example should be co-working with the code implemented in
    acpi_os_printf(). Since this KDB example won't be compiled unless
    ENABLE_DEBUGGER is defined and it seems Linux has already stopped to
    use ENABLE_DEBUGGER, thus do not expect it can work properly.

This patch also cleans up all other ACPI_FUTURE_USAGE surroundings
accordingly.
1. Since linkage error can be automatically detected, declaration in the
   headers needn't be surrounded by ACPI_FUTURE_USAGE.
   So only the following separate exported fuction bodies are masked by
   this macro (other exported fucntions may have already been masked at
   entire module level via drivers/acpi/acpica/Makefile):
     acpi_install_exception_handler()
     acpi_subsystem_status()
     acpi_get_system_info()
     acpi_get_statistics()
     acpi_install_initialization_handler()
2. Since strip can automatically zap the no-user functions, functions that
   are not marked with ACPI_EXPORT_SYMBOL() needn't get surrounded by
   ACPI_FUTURE_USAGE.
   So the following function which is not used by Linux kernel now won't
   get surrounded by this macro:
     acpi_ps_get_name()
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4d946f79
  13. 15 10月, 2015 1 次提交
  15. 25 8月, 2015 1 次提交
  17. 07 8月, 2015 1 次提交
    • L
      ACPI / sysfs: Update method tracing facility. · 7901a052
      由 Lv Zheng 提交于 
      This patch updates the method tracing facility as the acpi_debug_trace()
API has been updated to allow it to trace AML interpreter execution, the
meanings and the usages of the API parameters are changed due to the
updates.

The new API:
1. Uses ACPI_TRACE_ENABLED flag to indicate the enabling of the tracer;
2. Allows tracer still can be enabled when method name is not specified so
   that the AML interpreter execution can be traced without knowing the
   method name, which is useful for kernel boot tracing;
3. Supports arbitrary full path name, it doesn't need to be a name related
   to an entrance of acpi_evaluate_object().

Note that the sysfs parameters are also updated so that when reading the
attribute files, ACPICA internal settings are returned.

In order to make the sysfs parameters (acpi.trace_state) available during
boot, this patch adds code to bypass ACPICA semaphore/mutex invocations
when acpi mutex utilities haven't been initialized.

This patch doesn't update documentation of method tracing facility, it will
be updated by further patches.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7901a052
  19. 08 7月, 2015 1 次提交
  21. 07 7月, 2015 1 次提交
    • R
      ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage · 0294112e
      由 Rafael J. Wysocki 提交于 
      This effectively reverts the following three commits:

 7bc10388 ACPI / resources: free memory on error in add_region_before()
 0f1b414d ACPI / PNP: Avoid conflicting resource reservations
 b9a5e5e1 ACPI / init: Fix the ordering of acpi_reserve_resources()

(commit b9a5e5e1 introduced regressions some of which, but not
all, were addressed by commit 0f1b414d and commit 7bc10388
was a fixup on top of the latter) and causes ACPI fixed hardware
resources to be reserved at the fs_initcall_sync stage of system
initialization.

The story is as follows.  First, a boot regression was reported due
to an apparent resource reservation ordering change after a commit
that shouldn't lead to such changes.  Investigation led to the
conclusion that the problem happened because acpi_reserve_resources()
was executed at the device_initcall() stage of system initialization
which wasn't strictly ordered with respect to driver initialization
(and with respect to the initialization of the pcieport driver in
particular), so a random change causing the device initcalls to be
run in a different order might break things.

The response to that was to attempt to run acpi_reserve_resources()
as soon as we knew that ACPI would be in use (commit b9a5e5e1).
However, that turned out to be too early, because it caused resource
reservations made by the PNP system driver to fail on at least one
system and that failure was addressed by commit 0f1b414d.

That fix still turned out to be insufficient, though, because
calling acpi_reserve_resources() before the fs_initcall stage of
system initialization caused a boot regression to happen on the
eCAFE EC-800-H20G/S netbook.  That meant that we only could call
acpi_reserve_resources() at the fs_initcall initialization stage
or later, but then we might just as well call it after the PNP
initalization in which case commit 0f1b414d wouldn't be
necessary any more.

For this reason, the changes made by commit 0f1b414d are reverted
(along with a memory leak fixup on top of that commit), the changes
made by commit b9a5e5e1 that went too far are reverted too and
acpi_reserve_resources() is changed into fs_initcall_sync, which
will cause it to be executed after the PNP subsystem initialization
(which is an fs_initcall) and before device initcalls (including
the pcieport driver initialization) which should avoid the initial
issue.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=100581
Link: http://marc.info/?t=143092384600002&r=1&w=2
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831
Link: http://marc.info/?t=143389402600001&r=1&w=2
Fixes: b9a5e5e1 "ACPI / init: Fix the ordering of acpi_reserve_resources()"
Reported-by: NRoland Dreier <roland@purestorage.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0294112e
  23. 03 7月, 2015 1 次提交
    • R
      ACPI / init: Make it possible to override _REV · 18d78b64
      由 Rafael J. Wysocki 提交于 
      The platform firmware on some systems expects Linux to return "5" as
the supported ACPI revision which makes it expose system configuration
information in a special way.

For example, based on what ACPI exports as the supported revision,
Dell XPS 13 (2015) configures its audio device to either work in HDA
mode or in I2S mode, where the former is supposed to be used on Linux
until the latter is fully supported (in the kernel as well as in user
space).

Since ACPI 6 mandates that _REV should return "2" if ACPI 2 or later
is supported by the OS, a subsequent change will make that happen, so
make it possible to override that on systems where "5" is expected to
be returned for Linux to work correctly one them (such as the Dell
machine mentioned above).
Original-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      18d78b64
  25. 19 6月, 2015 2 次提交
  27. 15 5月, 2015 1 次提交
  29. 08 5月, 2015 1 次提交
  31. 25 3月, 2015 1 次提交
  33. 12 11月, 2014 2 次提交
    • L
      ACPI / OSL: Add IRQ handler flushing support in the OSL. · 90253a79
      由 Lv Zheng 提交于 
      It is possible that a GPE handler or a fixed event handler still accessed
after removing the handlers by invoking acpi_remove_gpe_handler() or
acpi_remove_fixed_event_handler(), this possibility can crash OPSM after a
module removal. In the Linux kernel, though all other GPE drivers are not
modules, since the IPMI_SI (ipmi_si_intf.c) can be compiled as a module, we
still need to consider a solution for this issue when the driver switches
to ACPI_GPE_RAW_HANDLER mode in order to invoke GPE APIs.

ACPICA expects acpi_os_wait_events_complete() to be invoked after GPE
disabling so that OSPM can ensure all running GPE handlers have exitted.
But currently acpi_os_wait_events_complete() can only flush _Lxx/_Exx
evaluation work queue and this philosophy cannot work for drivers that have
installed a dedicated GPE handler.

The only way to protect a callback is to perform some state holders
(reference count, state machine) before invoking the callback. Then this
issue can only be fixed by the following means:
1. Flush GPE in ACPICA before invoking the GPE handler. But currently,
   there is no such implementation in acpi_ev_gpe_dispatch().
2. Flush GPE in ACPICA OSL before invoking the SCI handler. But currently,
   there is no such implementation in acpi_irq().
3. Flush IRQ in OSPM IRQ layer before invoking the IRQ handler. In Linus
   kernel, this can be done by synchronize_irq().
4. Flush scheduling in OSPM vector entry layer before invoking the vector.
   In Linux, this can be done by synchronize_sched().

Since ACPICA expects the GPE handlers to be flushed by the ACPICA OSL or
the GPE drivers. If it is implemented by the GPE driver, we should see
synchronize_irq()/synchronize_sched() invoked in such drivers. If it is
implemented by the ACPICA OSL, ACPICA currently provides
acpi_os_wait_events_complete() hook to achieve this. After the following
commit:
  Commit: 69c841b6
  Author: Lv Zheng <lv.zheng@intel.com>
  Subject: ACPICA: Update use of acpi_os_wait_events_complete interface.
The OSL acpi_os_wait_events_complete() is invoked after a GPE handler is
removed from acpi_remove_gpe_handler() or a fixed event handler is removed
from acpi_remove_fixed_event_handler(). Thus it is possible to implement
GPE handler flushing using this ACPICA OSL now. So the solution 1 is
currently not taken into account.

By examining the IPMI_SI driver, we noticed that the IPMI_SI driver:
1. Uses free_irq() to flush non GPE based IRQ handlers, in free_irq(),
   synchronize_irq() is invoked, and
2. Uses acpi_remove_gpe_handler() to flush GPE based IRQ handlers, for such
   IRQ handlers, there is no synchronize_irq() invoked.
Since there isn't synchronize_sched() implemented for this driver, from the
driver's perspective, acpi_remove_gpe_handler() should have properly
flushed the GPE handlers for it. Since the driver doesn't invoke
synchronize_irq(), the solution 3 is not what the drivers expect.

This patch implements solution 2. But since given the fact that the GPE is
managed inside of ACPICA, and implementing the GPE flushing requires to
implement the whole GPE management code again in the OSL, instead of
flushing GPE, this patch flushes IRQ in acpi_os_wait_events_complete(). The
flushing could last longer than expected as though the target GPE/fixed
event that is removed can be fastly flushed, other GPEs/fix events can still
be issued during the flushing period.

This patch fixes this issue by invoking synchronize_hardirq() in
acpi_os_wait_events_complete(). The reason why we don't invoke
synchronize_irq() is: currently ACPICA is not threaded IRQ capable and the
only difference between synchronize_irq() and synchronize_hardirq() is
synchronize_irq() also flushes threaded IRQ handlers. Thus using
synchronize_hardirq() can help to reduce the overall synchronization time
for the current ACPICA implementation.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Corey Minyard <minyard@acm.org>
Cc: linux-acpi@vger.kernel.org
Cc: devel@acpica.org
Cc: openipmi-developer@lists.sourceforge.net
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      90253a79
    • K
      ACPI / osl: speedup grace period in acpi_os_map_cleanup · 74b51ee1
      由 Konstantin Khlebnikov 提交于 
      ACPI maintains cache of ioremap regions to speed up operations and
access to them from irq context where ioremap() calls aren't allowed.
This code abuses synchronize_rcu() on unmap path for synchronization
with fast-path in acpi_os_read/write_memory which uses this cache.

Since v3.10 CPUs are allowed to enter idle state even if they have RCU
callbacks queued, see commit c0f4dfd4
("rcu: Make RCU_FAST_NO_HZ take advantage of numbered callbacks").
That change caused problems with nvidia proprietary driver which calls
acpi_os_map/unmap_generic_address several times during initialization.
Each unmap calls synchronize_rcu and adds significant delay. Totally
initialization is slowed for a couple of seconds and that is enough to
trigger timeout in hardware, gpu decides to "fell off the bus". Widely
spread workaround is reducing "rcu_idle_gp_delay" from 4 to 1 jiffy.

This patch replaces synchronize_rcu() with synchronize_rcu_expedited()
which is much faster.

Link: https://devtalk.nvidia.com/default/topic/567297/linux/linux-3-10-driver-crash/Signed-off-by: NKonstantin Khlebnikov <koct9i@gmail.com>
Reported-and-tested-by: NAlexander Monakov <amonakov@gmail.com>
Reviewed-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      74b51ee1
  35. 01 10月, 2014 1 次提交
    • R
      ACPI / sleep: Rework the handling of ACPI GPE wakeup from suspend-to-idle · a8d46b9e
      由 Rafael J. Wysocki 提交于 
      The ACPI GPE wakeup from suspend-to-idle is currently based on using
the IRQF_NO_SUSPEND flag for the ACPI SCI, but that is problematic
for a couple of reasons.  First, in principle the ACPI SCI may be
shared and IRQF_NO_SUSPEND does not really work well with shared
interrupts.  Second, it may require the ACPI subsystem to special-case
the handling of device notifications depending on whether or not
they are received during suspend-to-idle in some places which would
lead to fragile code.  Finally, it's better the handle ACPI wakeup
interrupts consistently with wakeup interrupts from other sources.

For this reason, remove the IRQF_NO_SUSPEND flag from the ACPI SCI
and use enable_irq_wake()/disable_irq_wake() with it instead, which
requires two additional platform hooks to be added to struct
platform_freeze_ops.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a8d46b9e
  37. 25 9月, 2014 1 次提交
    • M
      ACPI: Support _OSI("Darwin") correctly · 7bc5a2ba
      由 Matthew Garrett 提交于 
      Apple hardware queries _OSI("Darwin") in order to determine whether the
system is running OS X, and changes firmware behaviour based on the
answer.  The most obvious difference in behaviour is that Thunderbolt
hardware is forcibly powered down unless the system is running OS X. The
obvious solution would be to simply add Darwin to the list of supported
_OSI strings, but this causes problems.

Recent Apple hardware includes two separate methods for checking _OSI
strings. The first will check whether Darwin is supported, and if so
will exit. The second will check whether Darwin is supported, but will
then continue to check for further operating systems. If a further
operating system is found then later firmware code will assume that the
OS is not OS X.  This results in the unfortunate situation where the
Thunderbolt controller is available at boot time but remains powered
down after suspend.

The easiest way to handle this is to special-case it in the
Linux-specific OSI handling code. If we see Darwin, we should answer
true and then disable all other _OSI vendor strings.

The next problem is that the Apple PCI _OSC method has the following
code:

if (LEqual (0x01, OSDW ()))
  if (LAnd (LEqual (Arg0, GUID), NEXP)
    (do stuff)
  else
    (fail)
NEXP is a value in high memory and is presumably under the control of
the firmware. No methods sets it. The methods that are called in the "do
stuff" path are dummies. Unless there's some additional firmware call in
early boot, there's no way for this call to succeed - and even if it
does, it doesn't do anything.

The easiest way to handle this is simply to ignore it. We know which
flags would be set, so just set them by hand if the platform is running
in Darwin mode.
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
[andreas.noever@gmail.com: merged two patches, do not touch ACPICA]
Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7bc5a2ba
  39. 21 7月, 2014 1 次提交
  41. 17 6月, 2014 1 次提交
  43. 05 6月, 2014 1 次提交
  45. 28 5月, 2014 1 次提交
    • L
      ACPI: Clean up acpi_os_map/unmap_memory() to eliminate __iomem. · a238317c
      由 Lv Zheng 提交于 
      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: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a238317c
  47. 21 4月, 2014 1 次提交
  49. 04 4月, 2014 1 次提交
  51. 26 3月, 2014 3 次提交
  53. 19 3月, 2014 1 次提交
  55. 05 3月, 2014 1 次提交
  57. 13 2月, 2014 1 次提交
    • L
      ACPICA: Add boot option to disable auto return object repair · 4dde507f
      由 Lv Zheng 提交于 
      Sometimes, there might be bugs caused by unexpected AML which is compliant
to the Windows but not compliant to the Linux implementation.

There is a predefined validation mechanism implemented in ACPICA to repair
the unexpected AML evaluation results that are caused by the unexpected
AMLs.  For example, BIOS may return misorder _CST result and the repair
mechanism can make an ascending order on the returned _CST package object
based on the C-state type.
This mechanism is quite useful to implement an AML interpreter with better
compliance with the real world where Windows is the de-facto standard and
BIOS codes are only tested on one platform thus not compliant to the
ACPI specification.

But if a compliance issue hasn't been figured out yet, it will be
difficult for developers to identify if the unexpected evaluation result
is caused by this mechanism or by the AML interpreter.
For example, _PR0 is expected to be a control method, but BIOS may use
Package: "Name(_PR0, Package(1) {P1PR})".
This boot option can disable the predefined validation mechanism so that
developers can make sure the root cause comes from the parser/executer.

This patch adds a new kernel parameter to disable this feature.

A build test has been made on a Dell Inspiron mini 1100 (i386 z530)
machine when this patch is applied and the corresponding boot test is
performed w/ or w/o the new kernel parameter specified.

References: https://bugzilla.kernel.org/show_bug.cgi?id=67901Tested-by: NFabian Wehning <fabian.wehning@googlemail.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4dde507f
  59. 06 1月, 2014 1 次提交