<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/acpi, branch v5.4.68</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.68</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.68'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2020-04-23T08:36:38Z</updated>
<entry>
<title>x86: ACPI: fix CPU hotplug deadlock</title>
<updated>2020-04-23T08:36:38Z</updated>
<author>
<name>Qian Cai</name>
<email>cai@lca.pw</email>
</author>
<published>2020-04-03T14:03:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=88591187bebc0140acb3901cb7e73c7442f92771'/>
<id>urn:sha1:88591187bebc0140acb3901cb7e73c7442f92771</id>
<content type='text'>
[ Upstream commit 696ac2e3bf267f5a2b2ed7d34e64131f2287d0ad ]

Similar to commit 0266d81e9bf5 ("acpi/processor: Prevent cpu hotplug
deadlock") except this is for acpi_processor_ffh_cstate_probe():

"The problem is that the work is scheduled on the current CPU from the
hotplug thread associated with that CPU.

It's not required to invoke these functions via the workqueue because
the hotplug thread runs on the target CPU already.

Check whether current is a per cpu thread pinned on the target CPU and
invoke the function directly to avoid the workqueue."

 WARNING: possible circular locking dependency detected
 ------------------------------------------------------
 cpuhp/1/15 is trying to acquire lock:
 ffffc90003447a28 ((work_completion)(&amp;wfc.work)){+.+.}-{0:0}, at: __flush_work+0x4c6/0x630

 but task is already holding lock:
 ffffffffafa1c0e8 (cpuidle_lock){+.+.}-{3:3}, at: cpuidle_pause_and_lock+0x17/0x20

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -&gt; #1 (cpu_hotplug_lock){++++}-{0:0}:
 cpus_read_lock+0x3e/0xc0
 irq_calc_affinity_vectors+0x5f/0x91
 __pci_enable_msix_range+0x10f/0x9a0
 pci_alloc_irq_vectors_affinity+0x13e/0x1f0
 pci_alloc_irq_vectors_affinity at drivers/pci/msi.c:1208
 pqi_ctrl_init+0x72f/0x1618 [smartpqi]
 pqi_pci_probe.cold.63+0x882/0x892 [smartpqi]
 local_pci_probe+0x7a/0xc0
 work_for_cpu_fn+0x2e/0x50
 process_one_work+0x57e/0xb90
 worker_thread+0x363/0x5b0
 kthread+0x1f4/0x220
 ret_from_fork+0x27/0x50

 -&gt; #0 ((work_completion)(&amp;wfc.work)){+.+.}-{0:0}:
 __lock_acquire+0x2244/0x32a0
 lock_acquire+0x1a2/0x680
 __flush_work+0x4e6/0x630
 work_on_cpu+0x114/0x160
 acpi_processor_ffh_cstate_probe+0x129/0x250
 acpi_processor_evaluate_cst+0x4c8/0x580
 acpi_processor_get_power_info+0x86/0x740
 acpi_processor_hotplug+0xc3/0x140
 acpi_soft_cpu_online+0x102/0x1d0
 cpuhp_invoke_callback+0x197/0x1120
 cpuhp_thread_fun+0x252/0x2f0
 smpboot_thread_fn+0x255/0x440
 kthread+0x1f4/0x220
 ret_from_fork+0x27/0x50

 other info that might help us debug this:

 Chain exists of:
 (work_completion)(&amp;wfc.work) --&gt; cpuhp_state-up --&gt; cpuidle_lock

 Possible unsafe locking scenario:

 CPU0                    CPU1
 ----                    ----
 lock(cpuidle_lock);
                         lock(cpuhp_state-up);
                         lock(cpuidle_lock);
 lock((work_completion)(&amp;wfc.work));

 *** DEADLOCK ***

 3 locks held by cpuhp/1/15:
 #0: ffffffffaf51ab10 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x69/0x2f0
 #1: ffffffffaf51ad40 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x69/0x2f0
 #2: ffffffffafa1c0e8 (cpuidle_lock){+.+.}-{3:3}, at: cpuidle_pause_and_lock+0x17/0x20

 Call Trace:
 dump_stack+0xa0/0xea
 print_circular_bug.cold.52+0x147/0x14c
 check_noncircular+0x295/0x2d0
 __lock_acquire+0x2244/0x32a0
 lock_acquire+0x1a2/0x680
 __flush_work+0x4e6/0x630
 work_on_cpu+0x114/0x160
 acpi_processor_ffh_cstate_probe+0x129/0x250
 acpi_processor_evaluate_cst+0x4c8/0x580
 acpi_processor_get_power_info+0x86/0x740
 acpi_processor_hotplug+0xc3/0x140
 acpi_soft_cpu_online+0x102/0x1d0
 cpuhp_invoke_callback+0x197/0x1120
 cpuhp_thread_fun+0x252/0x2f0
 smpboot_thread_fn+0x255/0x440
 kthread+0x1f4/0x220
 ret_from_fork+0x27/0x50

Signed-off-by: Qian Cai &lt;cai@lca.pw&gt;
Tested-by: Borislav Petkov &lt;bp@suse.de&gt;
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ACPICA: Allow acpi_any_gpe_status_set() to skip one GPE</title>
<updated>2020-04-17T08:50:09Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2020-03-25T10:54:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=dd993e283bc37164379121812870bd348746dba2'/>
<id>urn:sha1:dd993e283bc37164379121812870bd348746dba2</id>
<content type='text'>
commit 0ce792d660bda990c675eaf14ce09594a9b85cbf upstream.

The check carried out by acpi_any_gpe_status_set() is not precise enough
for the suspend-to-idle implementation in Linux and in some cases it is
necessary make it skip one GPE (specifically, the EC GPE) from the check
to prevent a race condition leading to a premature system resume from
occurring.

For this reason, redefine acpi_any_gpe_status_set() to take the number
of a GPE to skip as an argument.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=206629
Tested-by: Ondřej Caletka &lt;ondrej@caletka.cz&gt;
Cc: 5.4+ &lt;stable@vger.kernel.org&gt; # 5.4+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPICA: Introduce ACPI_ACCESS_BYTE_WIDTH() macro</title>
<updated>2020-03-05T15:43:42Z</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2020-02-12T14:59:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6b077e6fa7e2c0679982fd301c062943e4a05158'/>
<id>urn:sha1:6b077e6fa7e2c0679982fd301c062943e4a05158</id>
<content type='text'>
commit 1dade3a7048ccfc675650cd2cf13d578b095e5fb upstream.

Sometimes it is useful to find the access_width field value in bytes and
not in bits so add a helper that can be used for this purpose.

Suggested-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Cc: 4.16+ &lt;stable@vger.kernel.org&gt; # 4.16+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPI: PM: s2idle: Check fixed wakeup events in acpi_s2idle_wake()</title>
<updated>2020-02-28T16:22:20Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2020-02-21T00:46:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7b77e5a082247f85ec8ed7f1555f83751ea750c9'/>
<id>urn:sha1:7b77e5a082247f85ec8ed7f1555f83751ea750c9</id>
<content type='text'>
commit 63fb9623427fbb44e3782233b6e4714057b76ff2 upstream.

Commit fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from
waking up the system") overlooked the fact that fixed events can wake
up the system too and broke RTC wakeup from suspend-to-idle as a
result.

Fix this issue by checking the fixed events in acpi_s2idle_wake() in
addition to checking wakeup GPEs and break out of the suspend-to-idle
loop if the status bits of any enabled fixed events are set then.

Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system")
Reported-and-tested-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: 5.4+ &lt;stable@vger.kernel.org&gt; # 5.4+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPICA: Introduce acpi_any_gpe_status_set()</title>
<updated>2020-02-19T18:52:57Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2020-02-11T16:52:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3037406455674081a1377a511040e06c6aa86324'/>
<id>urn:sha1:3037406455674081a1377a511040e06c6aa86324</id>
<content type='text'>
commit ea128834dd76f9a72a35d011c651fa96658f06a7 upstream.

Introduce a new helper function, acpi_any_gpe_status_set(), for
checking the status bits of all enabled GPEs in one go.

It is needed to distinguish spurious SCIs from genuine ones when
deciding whether or not to wake up the system from suspend-to-idle.

Cc: 5.4+ &lt;stable@vger.kernel.org&gt; # 5.4+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPI / utils: Move acpi_dev_get_first_match_dev() under CONFIG_ACPI</title>
<updated>2019-12-17T18:56:29Z</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2019-10-01T14:27:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e9fcfbc239c0eb73a4775212f8872ce0520dedfe'/>
<id>urn:sha1:e9fcfbc239c0eb73a4775212f8872ce0520dedfe</id>
<content type='text'>
commit a814dcc269830c9dbb8a83731cfc6fc5dd787f8d upstream.

We have a stub defined for the acpi_dev_get_first_match_dev() in acpi.h
for the case when CONFIG_ACPI=n.

Moreover, acpi_dev_put(), counterpart function, is already placed under
CONFIG_ACPI.

Thus, move acpi_dev_get_first_match_dev() under CONFIG_ACPI as well.

Fixes: 817b4d64da03 ("ACPI / utils: Introduce acpi_dev_get_first_match_dev() helper")
Reported-by: kbuild test robot &lt;lkp@intel.com&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Cc: 5.2+ &lt;stable@vger.kernel.org&gt; # 5.2+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cpufreq: Use per-policy frequency QoS</title>
<updated>2019-10-21T00:05:21Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2019-10-16T10:47:06Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3000ce3c52f8b8db093e4dc649cd172390f71137'/>
<id>urn:sha1:3000ce3c52f8b8db093e4dc649cd172390f71137</id>
<content type='text'>
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 &lt;digetx@gmail.com&gt;
Tested-by: Dmitry Osipenko &lt;digetx@gmail.com&gt;
Reported-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Tested-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Diagnosed-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
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 &lt;rafael.j.wysocki@intel.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'acpi-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm</title>
<updated>2019-09-18T02:31:36Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2019-09-18T02:31:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d2aaa49e281959828370667edbc1cdcc7fc4026a'/>
<id>urn:sha1:d2aaa49e281959828370667edbc1cdcc7fc4026a</id>
<content type='text'>
Pull ACPI updates from Rafael Wysocki:
 "These include an ACPICA update (to upstream revision 20190816),
  improvements of support for memory hot-add in the HMAT handling code
  and some assorted fixes and cleanups.

  Specifics:

   - Update the ACPICA code in the kernel to upstream revision 20190816
     including:
      * Internal limits change to support larger systems (Bob Moore).
      * Macros clean up (Bob Moore).
      * printf format string fixes (Bob Moore).
      * Full deployment of the ACPI_PRINTF_LIKE macro (Bob Moore).
      * Tools improvements (Bob Moore, Colin Ian King).
      * Windows _OSI support fixes (Jung-uk Kim).

   - Improve memory hot-add support in the ACPI HMAT handling code (Dan
     Williams, Keith Busch).

   - Fix the ACPI LPSS (Low-Power Subsystem) driver for Intel SoCs to
     save and restore private registers during system-wide suspend and
     resume on systems with the Lynxpoint PCH (Jarkko Nikula).

   - Convert the ACPI documentation related to LEDs to ReST (Sakari
     Ailus).

   - Fix assorted issues and make assorted minor improvements in the
     ACPI-related code (Al Stone, Andy Shevchenko, Jiri Slaby, Kelsey
     Skunberg, Krzysztof Wilczynski, Liguang Zhang, Wenwen Wang,
     YueHaibing)"

* tag 'acpi-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (23 commits)
  ACPI / PCI: fix acpi_pci_irq_enable() memory leak
  ACPI: custom_method: fix memory leaks
  ACPI: thermal: Remove redundant acpi_has_method() calls
  ACPI / CPPC: do not require the _PSD method
  ACPI: SBS: remove unused const variable 'SMBUS_PEC'
  ACPI / LPSS: Save/restore LPSS private registers also on Lynxpoint
  ACPI/PCI: Remove surplus parentheses from a return statement
  ACPICA: Update version to 20190816.
  ACPICA: Add "Windows 2019" string to _OSI support.
  ACPICA: Differentiate Windows 8.1 from Windows 8.
  ACPICA: Fully deploy ACPI_PRINTF_LIKE macro
  ACPICA: iASL,acpi_dump: Improve y/n query
  ACPICA: Fix issues with arg types within printf format strings
  ACPICA: Macros: remove pointer math on a null pointer
  ACPICA: Increase total number of possible Owner IDs
  ACPICA: Debugger: remove redundant assignment on obj_desc
  Documentation: ACPI: DSD: Convert LED documentation to ReST
  ACPI / APEI: Release resources if gen_pool_add() fails
  HMAT: Skip publishing target info for nodes with no online memory
  HMAT: Register attributes for memory hot add
  ...
</content>
</entry>
<entry>
<title>Merge branch 'pm-cpufreq'</title>
<updated>2019-09-17T07:44:29Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2019-09-17T07:44:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ca61a72ac371b5a12fafd36248b93431c6694c3c'/>
<id>urn:sha1:ca61a72ac371b5a12fafd36248b93431c6694c3c</id>
<content type='text'>
* pm-cpufreq: (36 commits)
  cpufreq: Add qcs404 to cpufreq-dt-platdev blacklist
  cpufreq: qcom: Add support for qcs404 on nvmem driver
  cpufreq: qcom: Refactor the driver to make it easier to extend
  cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem based qcom socs
  dt-bindings: opp: Add qcom-opp bindings with properties needed for CPR
  dt-bindings: opp: qcom-nvmem: Support pstates provided by a power domain
  Documentation: cpufreq: Update policy notifier documentation
  cpufreq: Remove CPUFREQ_ADJUST and CPUFREQ_NOTIFY policy notifier events
  sched/cpufreq: Align trace event behavior of fast switching
  ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier
  video: pxafb: Remove cpufreq policy notifier
  video: sa1100fb: Remove cpufreq policy notifier
  arch_topology: Use CPUFREQ_CREATE_POLICY instead of CPUFREQ_NOTIFY
  cpufreq: powerpc_cbe: Switch to QoS requests for freq limits
  cpufreq: powerpc: macintosh: Switch to QoS requests for freq limits
  cpufreq: Print driver name if cpufreq_suspend() fails
  cpufreq: mediatek: Add support for mt8183
  cpufreq: mediatek: change to regulator_get_optional
  cpufreq: imx-cpufreq-dt: Add i.MX8MN support
  cpufreq: Use imx-cpufreq-dt for i.MX8MN's speed grading
  ...
</content>
</entry>
<entry>
<title>ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier</title>
<updated>2019-08-28T09:21:53Z</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2019-08-28T08:50:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d15ce412737accaba5e4c7d653b184772da47365'/>
<id>urn:sha1:d15ce412737accaba5e4c7d653b184772da47365</id>
<content type='text'>
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 &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
</feed>
