linux.git/drivers/acpi/processor_driver.c, branch v6.6.131

ACPI: processor: Reorder acpi_processor_driver_init()

2023-03-22T14:20:38+00:00

The cpufreq policy notifier in the ACPI processor driver may as
well be registered before the driver itself, which causes
acpi_processor_cpufreq_init to be true (unless the notifier
registration fails, which is unlikely at that point) when the
ACPI CPU thermal cooling devices are registered, so the
processor_get_max_state() result does not change while
acpi_processor_driver_init() is running.

Change the ordering in acpi_processor_driver_init() accordingly
to prevent the max_state value from remaining 0 permanently for all
ACPI CPU cooling devices due to setting acpi_processor_cpufreq_init
too late.  [Note that processor_get_max_state() may still return
different values at different times after this change, depending on
the cpufreq driver registration time, but that issue needs to be
addressed separately.]

Fixes: a365105c685c("thermal: sysfs: Reuse cdev->max_state")
Reported-by: Wang, Quanxian 
Link: https://lore.kernel.org/linux-pm/53ec1f06f61c984100868926f282647e57ecfb2d.camel@intel.com
Signed-off-by: Rafael J. Wysocki 
Tested-by: Zhang Rui 
Reviewed-by: Zhang Rui

ACPI: processor: Split out thermal initialization from ACPI PSS

2022-06-29T16:51:22+00:00

Commit 239708a3af44 ("ACPI: Split out ACPI PSS from ACPI Processor
driver"), moves processor thermal registration to acpi_pss_perf_init(),
which doesn't get executed if ACPI_CPU_FREQ_PSS is not enabled.

As ARM64 supports P-states using CPPC, it should be possible to also
support processor passive cooling even if PSS is not enabled. Split
out the processor thermal cooling register from ACPI PSS to support
this, and move it into a separate function in processor_thermal.c.

Signed-off-by: Riwen Lu 
Reviewed-by: Punit Agrawal 
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki

ACPI: Use acpi_fetch_acpi_dev() instead of acpi_bus_get_device()

2021-12-17T17:45:51+00:00

Modify the ACPI code to use acpi_fetch_acpi_dev() instead of
acpi_bus_get_device() where applicable.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg 
Reviewed-by: Hans de Goede

ACPI: processor: Get rid of ACPICA message printing

2021-03-08T15:51:19+00:00

The ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() macros are used for
message printing in the ACPICA code and they should not be used
elsewhere.  Special configuration (either kernel command line or
sysfs-based) is needed to see the messages printed by them and
the format of those messages is also special and convoluted.

For this reason, replace all of the ACPI_DEBUG_PRINT() and
ACPI_EXCEPTION() instances in the ACPI processor driver with
corresponding dev_*(), acpi_handle_*() and pr_*() calls depending
on the context in which they appear.

Also drop the ACPI_PROCESSOR_COMPONENT definition that is not going
to be necessary any more.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Hanjun Guo

cpufreq: Use per-policy frequency QoS

2019-10-21T00:05:21+00:00

Replace the CPU device PM QoS used for the management of min and max
frequency constraints in cpufreq (and its users) with per-policy
frequency QoS to avoid problems with cpufreq policies covering
more then one CPU.

Namely, a cpufreq driver is registered with the subsys interface
which calls cpufreq_add_dev() for each CPU, starting from CPU0, so
currently the PM QoS notifiers are added to the first CPU in the
policy (i.e. CPU0 in the majority of cases).

In turn, when the cpufreq driver is unregistered, the subsys interface
doing that calls cpufreq_remove_dev() for each CPU, starting from CPU0,
and the PM QoS notifiers are only removed when cpufreq_remove_dev() is
called for the last CPU in the policy, say CPUx, which as a rule is
not CPU0 if the policy covers more than one CPU.  Then, the PM QoS
notifiers cannot be removed, because CPUx does not have them, and
they are still there in the device PM QoS notifiers list of CPU0,
which prevents new PM QoS notifiers from being registered for CPU0
on the next attempt to register the cpufreq driver.

The same issue occurs when the first CPU in the policy goes offline
before unregistering the driver.

After this change it does not matter which CPU is the policy CPU at
the driver registration time and whether or not it is online all the
time, because the frequency QoS is per policy and not per CPU.

Fixes: 67d874c3b2c6 ("cpufreq: Register notifiers with the PM QoS framework")
Reported-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
Reported-by: Sudeep Holla 
Tested-by: Sudeep Holla 
Diagnosed-by: Viresh Kumar 
Link: https://lore.kernel.org/linux-pm/5ad2624194baa2f53acc1f1e627eb7684c577a19.1562210705.git.viresh.kumar@linaro.org/T/#md2d89e95906b8c91c15f582146173dce2e86e99f
Link: https://lore.kernel.org/linux-pm/20191017094612.6tbkwoq4harsjcqv@vireshk-i7/T/#m30d48cc23b9a80467fbaa16e30f90b3828a5a29b
Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar

ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier

2019-08-28T09:21:53+00:00

The cpufreq core now takes the min/max frequency constraints via QoS
requests and the CPUFREQ_ADJUST notifier shall get removed later on.

Switch over to using the QoS request for maximum frequency constraint
for acpi driver.

Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157

2019-05-30T18:26:37+00:00

Based on 3 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version this program is distributed in the
  hope that it will be useful but without any warranty without even
  the implied warranty of merchantability or fitness for a particular
  purpose see the gnu general public license for more details

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version [author] [kishon] [vijay] [abraham]
  [i] [kishon]@[ti] [com] this program is distributed in the hope that
  it will be useful but without any warranty without even the implied
  warranty of merchantability or fitness for a particular purpose see
  the gnu general public license for more details

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version [author] [graeme] [gregory]
  [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i]
  [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema]
  [hk] [hemahk]@[ti] [com] this program is distributed in the hope
  that it will be useful but without any warranty without even the
  implied warranty of merchantability or fitness for a particular
  purpose see the gnu general public license for more details

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 1105 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Allison Randal 
Reviewed-by: Richard Fontana 
Reviewed-by: Kate Stewart 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de
Signed-off-by: Greg Kroah-Hartman

ACPI: processor: use dev_dbg() instead of dev_warn() when CPPC probe failed

2017-07-26T23:51:06+00:00

_CPC is a optinal object for processor device so it's
fine for processor devices in DSDT without CPPC data,
but when booting the system with CPPC enabled in the
kernel but without its support in the firmware, I got
lots of warnings on a 64 core system:

[    6.346016] acpi ACPI0007:00: CPPC data invalid or not present
[    6.346028] acpi ACPI0007:01: CPPC data invalid or not present
[    6.346039] acpi ACPI0007:02: CPPC data invalid or not present
[    6.346050] acpi ACPI0007:03: CPPC data invalid or not present
[    6.346063] acpi ACPI0007:04: CPPC data invalid or not present
...
[    6.346737] acpi ACPI0007:3f: CPPC data invalid or not present

This isn't much useful and a little bit noise, so
switch the dev_warn() to dev_dbg().

Signed-off-by: Hanjun Guo 
Signed-off-by: Rafael J. Wysocki

ACPI/processor: Use cpu_hotplug_disable() instead of get_online_cpus()

2017-05-26T08:10:44+00:00

Converting the hotplug locking, i.e. get_online_cpus(), to a percpu rwsem
unearthed a circular lock dependency which was hidden from lockdep due to
the lockdep annotation of get_online_cpus() which prevents lockdep from
creating full dependency chains.

CPU0                    CPU1
----                    ----
lock((&wfc.work));
                         lock(cpu_hotplug_lock.rw_sem);
                         lock((&wfc.work));
lock(cpu_hotplug_lock.rw_sem);

This dependency is established via acpi_processor_start() which calls into
the work queue code. And the work queue code establishes the reverse
dependency.

This is not a problem of get_online_cpus() recursion, it's a possible
deadlock undetected by lockdep so far.

The cure is to use cpu_hotplug_disable() instead of get_online_cpus() to
protect the probing from acpi_processor_start().

There is a side effect to this: cpu_hotplug_disable() makes a concurrent
cpu hotplug attempt via the sysfs interfaces fail with -EBUSY, but that
probing usually happens during the boot process where no interaction is
possible. Any later invocations are infrequent enough and concurrent
hotplug attempts are so unlikely that the danger of user space visible
regressions is very close to zero. Anyway, thats preferrable over a real
deadlock.

Signed-off-by: Thomas Gleixner 
Acked-by: Ingo Molnar 
Acked-by: Rafael J. Wysocki 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Sebastian Siewior 
Cc: Steven Rostedt 
Cc: linux-acpi@vger.kernel.org
Cc: Len Brown 
Link: http://lkml.kernel.org/r/20170524081548.851588594@linutronix.de

ACPI/processor: Replace racy task affinity logic

2017-04-15T10:20:54+00:00

acpi_processor_get_throttling() requires to invoke the getter function on
the target CPU. This is achieved by temporarily setting the affinity of the
calling user space thread to the requested CPU and reset it to the original
affinity afterwards.

That's racy vs. CPU hotplug and concurrent affinity settings for that
thread resulting in code executing on the wrong CPU and overwriting the
new affinity setting.

acpi_processor_get_throttling() is invoked in two ways:

1) The CPU online callback, which is already running on the target CPU and
   obviously protected against hotplug and not affected by affinity
   settings.

2) The ACPI driver probe function, which is not protected against hotplug
   during modprobe.

Switch it over to work_on_cpu() and protect the probe function against CPU
hotplug.

Signed-off-by: Thomas Gleixner 
Cc: Fenghua Yu 
Cc: Tony Luck 
Cc: Herbert Xu 
Cc: "Rafael J. Wysocki" 
Cc: Peter Zijlstra 
Cc: Benjamin Herrenschmidt 
Cc: Sebastian Siewior 
Cc: Lai Jiangshan 
Cc: linux-acpi@vger.kernel.org
Cc: Viresh Kumar 
Cc: Michael Ellerman 
Cc: Tejun Heo 
Cc: "David S. Miller" 
Cc: Len Brown 
Link: http://lkml.kernel.org/r/20170412201042.785920903@linutronix.de
Signed-off-by: Thomas Gleixner