Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 04 2月, 2021 1 次提交
    • M
      ACPI: Execute platform _OSC also with query bit clear · 719e1f56
      由 Mario Limonciello 提交于 
      The platform _OSC can change the hardware state when query bit is not
set. According to ACPI spec it is recommended that the OS runs _OSC with
query bit set until the platform does not mask any of the capabilities.
Then it should run it with query bit clear in order to actually commit
the changes. Linux has not been doing this for the reasons that there
has not been anything to commit, until now.

The ACPI 6.4 introduced _OSC for USB4 to allow the OS to negotiate
native control over USB4 tunneling. The platform might implement this so
that it only activates the software connection manager path when the OS
calls the _OSC with the query bit clear. Otherwise it may default to the
firmware connection manager, for instance.

For this reason modify the _OSC support so that we first execute it with
query bit set, then use the returned value as base of the features we
want to control and run the _OSC again with query bit clear. This also
follows what Windows is doing.

Also rename the function to better match what it does.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      719e1f56
  3. 18 12月, 2020 5 次提交
    • R
      ACPI: PM: s2idle: Move x86-specific code to the x86 directory · fef98671
      由 Rafael J. Wysocki 提交于 
      Some code in drivers/acpi/sleep.c (which is regarded as a generic
file) related to suspend-to-idle support has grown direct dependencies
on x86, but in fact it has been specific to x86 (which is the only
user of it) anyway for a long time.

For this reason, move that code to a separate file under acpi/x86/
and make it build and run as before under the right conditions.

While at it, rename a vendor checking function in that code and
consistently use acpi_handle_debug() for printing debug-related
information in it.

No expected functional impact.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fef98671
    • H
      ACPI: scan: Add Intel Baytrail Mailbox Device to acpi_ignore_dep_ids · 9272e97a
      由 Hans de Goede 提交于 
      Linux does not have a driver for / does not use the "Intel Baytrail
Mailbox Device" (ACIP HID INT33BD). Add it to the acpi_ignore_dep_ids
list, so that we do not defer probing ACPI devices which depend on
another ACPI device with this HID.

Specifically this makes us not defer the probing of the GPO1 ACPI
device / GPIO controller on the Acer Switch 10E SW3-016. On this
tablet model the  _HID method of the ACPI node for the UART attached
Bluetooth, reads GPIOs to detect the installed wifi chip and updates
the reported _HID for the Bluetooth's ACPI node accordingly.

For the Bluetooth's ACPI node to report the correct _HID the GPO1 device
must be probed and attached during the first scan pass. Adding the
"INT33BD" HID to the acpi_ignore_dep_ids list makes this all work.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9272e97a
    • R
      ACPI: scan: Avoid unnecessary second pass in acpi_bus_scan() · 0de7fb7c
      由 Rafael J. Wysocki 提交于 
      If there are no devices whose enumeration has been deferred after
the first pass in acpi_bus_scan(), the second pass is not necssary,
so avoid it with the help of a new static variable.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      0de7fb7c
    • R
      ACPI: scan: Defer enumeration of devices with _DEP lists · 71da201f
      由 Rafael J. Wysocki 提交于 
      In some cases ACPI control methods used during device enumeration
(such as _HID or _STA) may rely on Operation Region handlers
supplied by the drivers of other devices [1]:

 An example of this is the Acer Switch 10E SW3-016 model. The _HID
 method of the ACPI node for the UART attached Bluetooth, reads
 GPIOs to detect the installed wifi chip and update the _HID for the
 Bluetooth's ACPI node accordingly. The current ACPI scan code calls
 _HID before the GPIO controller's OpRegions are available, leading
 to the wrong _HID being used and Bluetooth not working.

In principle, in those cases there should be a _DEP control method
under the device object with OpRegion enumeration dependencies, so
deferring the enumeration of devices with _DEP returning a non-empty
list of suppliers of OpRegions depended on by the given device
(modulo some known exceptions that don't really supply any OpRegions
and are listed by _DEP for other reasons irrelevant for Linux) should
at least address the first-order dependencies by allowing the OpRegion
suppliers to be enumerated before their consumers.

Implement the above idea by modifying acpi_bus_scan() to enumerate
devices in the given scope of the ACPI namespace in two passes,
where the first pass covers the devices without "significant" lists
of dependencies coming from _DEP only and the second pass covers
all of the devices that were not enumerated in the first pass.

Take _DEP into account only for device objects with _HID, mostly in
order to avoid deferring the creation of ACPI device objects that
represent PCI devices and must be present during the enumeration
of the PCI bus (which takes place during the processing of the ACPI
device object that represents the host bridge), so that they can
be properly associated with the corresponding PCI devices.

Link: https://lore.kernel.org/linux-acpi/20201121203040.146252-1-hdegoede@redhat.com/ # [1]
Reported-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      71da201f
    • R
      ACPI: scan: Evaluate _DEP before adding the device · 6fc25088
      由 Rafael J. Wysocki 提交于 
      Evaluate _DEP before calling acpi_add_single_object() from
acpi_bus_check_add() and do that only for ACPI_BUS_TYPE_DEVICE
objects.

While at it, rename acpi_device_dep_initialize() to
acpi_scan_check_dep(), fix up a memory allocation statement in
that function, consistently treat memory allocation failures in
there as intermittent errors and make some related janitorial
changes in it.

This change will help to avoid calling acpi_add_single_object() if
there are unmet _DEP dependencies in the future, as that may cause
some control methods, potentially depending on the presence of
operation regions supplied by other devices, to be evaluated
prematurely.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      6fc25088
  5. 17 12月, 2020 1 次提交
  7. 16 12月, 2020 3 次提交
    • H
      ACPI: PNP: compare the string length in the matching_id() · b08221c4
      由 Hui Wang 提交于 
      Recently we met a touchscreen problem on some Thinkpad machines, the
touchscreen driver (i2c-hid) is not loaded and the touchscreen can't
work.

An i2c ACPI device with the name WACF2200 is defined in the BIOS, with
the current rule in matching_id(), this device will be regarded as
a PNP device since there is WACFXXX in the acpi_pnp_device_ids[] and
this PNP device is attached to the acpi device as the 1st
physical_node, this will make the i2c bus match fail when i2c bus
calls acpi_companion_match() to match the acpi_id_table in the i2c-hid
driver.

WACF2200 is an i2c device instead of a PNP device, after adding the
string length comparing, the matching_id() will return false when
matching WACF2200 and WACFXXX, and it is reasonable to compare the
string length when matching two IDs.
Suggested-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b08221c4
    • I
      cppc_cpufreq: replace per-cpu data array with a list · a28b2bfc
      由 Ionela Voinescu 提交于 
      The cppc_cpudata per-cpu storage was inefficient (1) additional to causing
functional issues (2) when CPUs are hotplugged out, due to per-cpu data
being improperly initialised.

(1) The amount of information needed for CPPC performance control in its
    cpufreq driver depends on the domain (PSD) coordination type:

    ANY:    One set of CPPC control and capability data (e.g desired
            performance, highest/lowest performance, etc) applies to all
            CPUs in the domain.

    ALL:    Same as ANY. To be noted that this type is not currently
            supported. When supported, information about which CPUs
            belong to a domain is needed in order for frequency change
            requests to be sent to each of them.

    HW:     It's necessary to store CPPC control and capability
            information for all the CPUs. HW will then coordinate the
            performance state based on their limitations and requests.

    NONE:   Same as HW. No HW coordination is expected.

    Despite this, the previous initialisation code would indiscriminately
    allocate memory for all CPUs (all_cpu_data) and unnecessarily
    duplicate performance capabilities and the domain sharing mask and type
    for each possible CPU.

(2) With the current per-cpu structure, when having ANY coordination,
    the cppc_cpudata cpu information is not initialised (will remain 0)
    for all CPUs in a policy, other than policy->cpu. When policy->cpu is
    hotplugged out, the driver will incorrectly use the uninitialised (0)
    value of the other CPUs when making frequency changes. Additionally,
    the previous values stored in the perf_ctrls.desired_perf will be
    lost when policy->cpu changes.

Therefore replace the array of per cpu data with a list. The memory for
each structure is allocated at policy init, where a single structure
can be allocated per policy, not per cpu. In order to accommodate the
struct list_head node in the cppc_cpudata structure, the now unused cpu
and cur_policy variables are removed.

For example, on a arm64 Juno platform with 6 CPUs: (0, 1, 2, 3) in PSD1,
(4, 5) in PSD2 - ANY coordination, the memory allocation comparison shows:

Before patch:

 - ANY coordination:
   total    slack      req alloc/free  caller
       0        0        0     0/1     _kernel_size_le_hi32+0x0xffff800008ff7810
       0        0        0     0/6     _kernel_size_le_hi32+0x0xffff800008ff7808
     128       80       48     1/0     _kernel_size_le_hi32+0x0xffff800008ffc070
     768        0      768     6/0     _kernel_size_le_hi32+0x0xffff800008ffc0e4

After patch:

 - ANY coordination:
    total    slack      req alloc/free  caller
     256        0      256     2/0     _kernel_size_le_hi32+0x0xffff800008fed410
       0        0        0     0/2     _kernel_size_le_hi32+0x0xffff800008fed274

Additional notes:
 - A pointer to the policy's cppc_cpudata is stored in policy->driver_data
 - Driver registration is skipped if _CPC entries are not present.
Signed-off-by: NIonela Voinescu <ionela.voinescu@arm.com>
Tested-by: NMian Yousaf Kaukab <ykaukab@suse.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a28b2bfc
    • I
      ACPI: processor: fix NONE coordination for domain mapping failure · bca3e43c
      由 Ionela Voinescu 提交于 
      For errors parsing the _PSD domains, a separate domain is returned for
each CPU in the failed _PSD domain with no coordination (as per previous
comment). But contrary to the intention, the code was setting
CPUFREQ_SHARED_TYPE_ALL as coordination type.

Change shared_type to CPUFREQ_SHARED_TYPE_NONE in case of errors parsing
the domain information. The function still returns the error and the caller
is free to bail out the domain initialisation altogether in that case.

Given that both functions return domains with a single CPU, this change
does not affect the functionality, but clarifies the intention.
Signed-off-by: NIonela Voinescu <ionela.voinescu@arm.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
[ rjw: Subject edit ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bca3e43c
  9. 11 12月, 2020 2 次提交
  11. 10 12月, 2020 1 次提交
  13. 09 12月, 2020 2 次提交
  15. 07 12月, 2020 5 次提交
    • J
      ACPI: video: Add DMI quirk for GIGABYTE GB-BXBT-2807 · 25417185
      由 Jasper St. Pierre 提交于 
      The GIGABYTE GB-BXBT-2807 is a mini-PC which uses off the shelf
components, like an Intel GPU which is meant for mobile systems.
As such, it, by default, has a backlight controller exposed.

Unfortunately, the backlight controller only confuses userspace, which
sees the existence of a backlight device node and has the unrealistic
belief that there is actually a backlight there!

Add a DMI quirk to force the backlight off on this system.
Signed-off-by: NJasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: NChris Chiu <chiu@endlessos.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      25417185
    • D
      Revert "ACPI / resources: Use AE_CTRL_TERMINATE to terminate resources walks" · 12fc4dad
      由 Daniel Scally 提交于 
      This reverts commit 8a66790b.

Switching this function to AE_CTRL_TERMINATE broke the documented
behaviour of acpi_dev_get_resources() - AE_CTRL_TERMINATE does not, in
fact, terminate the resource walk because acpi_walk_resource_buffer()
ignores it (specifically converting it to AE_OK), referring to that
value as "an OK termination by the user function". This means that
acpi_dev_get_resources() does not abort processing when the preproc
function returns a negative value.
Signed-off-by: NDaniel Scally <djrscally@gmail.com>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      12fc4dad
    • R
      ACPI: scan: Add PNP0D80 to the _DEP exceptions list · 2ef33ee7
      由 Rafael J. Wysocki 提交于 
      The PNP0D80 ("Windows-compatible System Power Management Controller")
device ID is used for identifying the special device object providing
the LPI (Low-power S0 Idle) _DSM interface [1].  That device object
does not supply any operation regions, but it appears in _DEP lists
for other devices in the ACPI tables on some systems to enforce
specific enumeration ordering that does not matter for Linux.

For this reason, _DEP list entries pointing to the device object whose
_CID returns PNP0D80 need not be taken into account as real operation
region dependencies, so add that device ID to the list of device IDs
for which the matching _DEP list entries should be ignored.

Accordingly, update the function used for matching device IDs in that
list to allow it to check _CID as well as _HID and rename it to
acpi_info_matches_ids().

Link: https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf # [1]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2ef33ee7
    • R
      PM: ACPI: Refresh wakeup device power configuration every time · b93b7ef6
      由 Rafael J. Wysocki 提交于 
      When wakeup signaling is enabled for a bridge for the second (or every
next) time in a row, its existing device wakeup power configuration
may not match the new conditions.  For example, some devices below
it may have been put into low-power states and that changes the
device wakeup power conditions or similar.  This causes functional
problems to appear on some systems (for example,  because of it the
Thunderbolt port on Dell Precision 5550 cannot detect devices plugged
in after it has been suspended).

For this reason, modify __acpi_device_wakeup_enable() to refresh the
device wakeup power configuration of the target device on every
invocation, not just when it is called for that device first time
in a row.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reported-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      b93b7ef6
    • R
      PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup() · 7482c5cb
      由 Rafael J. Wysocki 提交于 
      The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to
be reference counted for wakeup enabling, because they may be enabled
to signal wakeup on behalf of their subordinate devices and that
may happen for multiple times in a row, whereas for the other devices
it only makes sense to enable wakeup signaling once.

However, this becomes problematic if the bridge itself is suspended,
because it is treated as a "regular" device in that case and the
reference counting doesn't work.

For instance, suppose that there are two devices below a bridge and
they both can signal wakeup.  Every time one of them is suspended,
wakeup signaling is enabled for the bridge, so when they both have
been suspended, the bridge's wakeup reference counter value is 2.

Say that the bridge is suspended subsequently and acpi_pci_wakeup()
is called for it.  Because the bridge can signal wakeup, that
function will invoke acpi_pm_set_device_wakeup() to configure it
and __acpi_pm_set_device_wakeup() will be called with the last
argument equal to 1.  This causes __acpi_device_wakeup_enable()
invoked by it to omit the reference counting, because the reference
counter of the target device (the bridge) is 2 at that time.

Now say that the bridge resumes and one of the device below it
resumes too, so the bridge's reference counter becomes 0 and
wakeup signaling is disabled for it, but there is still the other
suspended device which may need the bridge to signal wakeup on its
behalf and that is not going to work.

To address this scenario, use wakeup enable reference counting for
all devices, not just for bridges, so drop the last argument from
__acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(),
which causes acpi_pm_set_device_wakeup() and
acpi_pm_set_bridge_wakeup() to become identical, so drop the latter
and use the former instead of it everywhere.

Fixes: 1ba51a7c ("ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()")
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
      7482c5cb
  17. 02 12月, 2020 6 次提交
  19. 25 11月, 2020 1 次提交
  21. 24 11月, 2020 6 次提交
  23. 23 11月, 2020 2 次提交
    • S
      ACPI: EC: Eliminate in_interrupt() usage · 2e84ea5a
      由 Sebastian Andrzej Siewior 提交于 
      advance_transaction() is using in_interrupt() to distinguish between
an invocation from the interrupt handler and an invocation from
another part of the stack.

This looks misleading because chains like

  acpi_update_all_gpes() -> acpi_ev_gpe_detect() ->
  acpi_ev_detect_gpe() -> acpi_ec_gpe_handler()

should probably also behave as if they were called from an interrupt
handler.

Replace in_interrupt() usage with a function parameter.

Set this parameter to `true' if invoked from an interrupt handler
(acpi_ec_gpe_handler() and acpi_ec_irq_handler()) and `false'
otherwise.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
[ rjw: Subject edits ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2e84ea5a
    • S
      ACPI/IORT: Fix doc warnings in iort.c · 774c4a3b
      由 Shiju Jose 提交于 
      Fix following warnings caused by mismatch between
function parameters and function comments.

drivers/acpi/arm64/iort.c:55: warning: Function parameter or member 'iort_node' not described in 'iort_set_fwnode'
drivers/acpi/arm64/iort.c:55: warning: Excess function parameter 'node' description in 'iort_set_fwnode'
drivers/acpi/arm64/iort.c:682: warning: Function parameter or member 'id' not described in 'iort_get_device_domain'
drivers/acpi/arm64/iort.c:682: warning: Function parameter or member 'bus_token' not described in 'iort_get_device_domain'
drivers/acpi/arm64/iort.c:682: warning: Excess function parameter 'req_id' description in 'iort_get_device_domain'
drivers/acpi/arm64/iort.c:1142: warning: Function parameter or member 'dma_size' not described in 'iort_dma_setup'
drivers/acpi/arm64/iort.c:1142: warning: Excess function parameter 'size' description in 'iort_dma_setup'
drivers/acpi/arm64/iort.c:1534: warning: Function parameter or member 'ops' not described in 'iort_add_platform_device'
Signed-off-by: NShiju Jose <shiju.jose@huawei.com>
Acked-by: NHanjun Guo <guohanjun@huawei.com>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Link: https://lore.kernel.org/r/20201014093139.1580-1-shiju.jose@huawei.comSigned-off-by: NWill Deacon <will@kernel.org>
      774c4a3b
  25. 20 11月, 2020 1 次提交
    • A
      arm64: mm: Set ZONE_DMA size based on early IORT scan · 2b865293
      由 Ard Biesheuvel 提交于 
      We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge can only access the bottom 3 GB)

Instructing the DMA layer about these limitations is straight-forward,
even though we had to fix some issues regarding memory limits set in
the IORT for named components, and regarding the handling of ACPI _DMA
methods. However, the DMA layer also needs to be able to allocate
memory that is guaranteed to meet those DMA constraints, for bounce
buffering as well as allocating the backing for consistent mappings.

This is why the 1 GB ZONE_DMA was introduced recently. Unfortunately,
it turns out the having a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes
problems with kdump, and potentially in other places where allocations
cannot cross zone boundaries. Therefore, we should avoid having two
separate DMA zones when possible.

So let's do an early scan of the IORT, and only create the ZONE_DMA
if we encounter any devices that need it. This puts the burden on
the firmware to describe such limitations in the IORT, which may be
redundant (and less precise) if _DMA methods are also being provided.
However, it should be noted that this situation is highly unusual for
arm64 ACPI machines. Also, the DMA subsystem still gives precedence to
the _DMA method if implemented, and so we will not lose the ability to
perform streaming DMA outside the ZONE_DMA if the _DMA method permits
it.

[nsaenz: unified implementation with DT's counterpart]
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Tested-by: NJeremy Linton <jeremy.linton@arm.com>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NHanjun Guo <guohanjun@huawei.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20201119175400.9995-7-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      2b865293
  27. 19 11月, 2020 1 次提交
  29. 18 11月, 2020 3 次提交