linux-stable.git/drivers/acpi, branch v6.15.2 Linux kernel stable tree ACPICA: Apply ACPI_NONSTRING in more places 2025-06-10T11:17:08+00:00 Ahmed Salem x0rw3ll@gmail.com 2025-04-25T19:31:05+00:00 4c487424273629820a1d06771bbb1dd4e420368d commit 70662db73d5455ebc8a1da29973fa70237b18cd2 upstream. ACPICA commit 1035a3d453f7dd49a235a59ee84ebda9d2d2f41b Add ACPI_NONSTRING for destination char arrays without a terminating NUL character. This is a follow-up to commit 35ad99236f3a ("ACPICA: Apply ACPI_NONSTRING") where not all instances received the same treatment, in preparation for replacing strncpy() calls with memcpy() Link: https://github.com/acpica/acpica/commit/1035a3d4 Signed-off-by: Ahmed Salem <x0rw3ll@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3833065.MHq7AAxBmi@rjwysocki.net Cc: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 70662db73d5455ebc8a1da29973fa70237b18cd2 upstream.

ACPICA commit 1035a3d453f7dd49a235a59ee84ebda9d2d2f41b

Add ACPI_NONSTRING for destination char arrays without a terminating NUL
character. This is a follow-up to commit 35ad99236f3a ("ACPICA: Apply
ACPI_NONSTRING") where not all instances received the same treatment, in
preparation for replacing strncpy() calls with memcpy()

Link: https://github.com/acpica/acpica/commit/1035a3d4
Signed-off-by: Ahmed Salem <x0rw3ll@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/3833065.MHq7AAxBmi@rjwysocki.net
Cc: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ACPICA: Apply ACPI_NONSTRING 2025-06-10T11:17:08+00:00 Kees Cook kees@kernel.org 2025-04-25T19:28:34+00:00 692b9698a252dd3477585b7bf33b1af7954c637d commit 2b82118845e04c7adf4ece797150c19809bab29b upstream. ACPICA commit ed68cb8e082e3bfbba02814af4fd5a61247f491b Add ACPI_NONSTRING annotations for places found that are using char arrays without a terminating NUL character. These were found during Linux kernel builds and after looking for instances of arrays of size ACPI_NAMESEG_SIZE. Link: https://github.com/acpica/acpica/commit/ed68cb8e Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2039736.usQuhbGJ8B@rjwysocki.net Cc: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2b82118845e04c7adf4ece797150c19809bab29b upstream.

ACPICA commit ed68cb8e082e3bfbba02814af4fd5a61247f491b

Add ACPI_NONSTRING annotations for places found that are using char
arrays without a terminating NUL character. These were found during
Linux kernel builds and after looking for instances of arrays of size
ACPI_NAMESEG_SIZE.

Link: https://github.com/acpica/acpica/commit/ed68cb8e
Signed-off-by: Kees Cook <kees@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2039736.usQuhbGJ8B@rjwysocki.net
Cc: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ACPI: PPTT: Fix processor subtable walk 2025-05-08T18:23:16+00:00 Jeremy Linton jeremy.linton@arm.com 2025-05-08T02:30:25+00:00 adfab6b39202481bb43286fff94def4953793fdb The original PPTT code had a bug where the processor subtable length was not correctly validated when encountering a truncated acpi_pptt_processor node. Commit 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls") attempted to fix this by validating the size is as large as the acpi_pptt_processor node structure. This introduced a regression where the last processor node in the PPTT table is ignored if it doesn't contain any private resources. That results errors like: ACPI PPTT: PPTT table found, but unable to locate core XX (XX) ACPI: SPE must be homogeneous Furthermore, it fails in a common case where the node length isn't equal to the acpi_pptt_processor structure size, leaving the original bug in a modified form. Correct the regression by adjusting the loop termination conditions as suggested by the bug reporters. An additional check performed after the subtable node type is detected, validates the acpi_pptt_processor node is fully contained in the PPTT table. Repeating the check in acpi_pptt_leaf_node() is largely redundant as the node is already known to be fully contained in the table. The case where a final truncated node's parent property is accepted, but the node itself is rejected should not be considered a bug. Fixes: 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls") Reported-by: Maximilian Heyne <mheyne@amazon.de> Closes: https://lore.kernel.org/linux-acpi/20250506-draco-taped-15f475cd@mheyne-amazon/ Reported-by: Yicong Yang <yangyicong@hisilicon.com> Closes: https://lore.kernel.org/linux-acpi/20250507035124.28071-1-yangyicong@huawei.com/ Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Tested-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Maximilian Heyne <mheyne@amazon.de> Cc: All applicable <stable@vger.kernel.org> # 7ab4f0e37a0f4: ACPI PPTT: Fix coding mistakes ... Link: https://patch.msgid.link/20250508023025.1301030-1-jeremy.linton@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
The original PPTT code had a bug where the processor subtable length
was not correctly validated when encountering a truncated
acpi_pptt_processor node.

Commit 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of
sizeof() calls") attempted to fix this by validating the size is as
large as the acpi_pptt_processor node structure. This introduced a
regression where the last processor node in the PPTT table is ignored
if it doesn't contain any private resources. That results errors like:

  ACPI PPTT: PPTT table found, but unable to locate core XX (XX)
  ACPI: SPE must be homogeneous

Furthermore, it fails in a common case where the node length isn't
equal to the acpi_pptt_processor structure size, leaving the original
bug in a modified form.

Correct the regression by adjusting the loop termination conditions as
suggested by the bug reporters. An additional check performed after
the subtable node type is detected, validates the acpi_pptt_processor
node is fully contained in the PPTT table. Repeating the check in
acpi_pptt_leaf_node() is largely redundant as the node is already
known to be fully contained in the table.

The case where a final truncated node's parent property is accepted,
but the node itself is rejected should not be considered a bug.

Fixes: 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls")
Reported-by: Maximilian Heyne <mheyne@amazon.de>
Closes: https://lore.kernel.org/linux-acpi/20250506-draco-taped-15f475cd@mheyne-amazon/
Reported-by: Yicong Yang <yangyicong@hisilicon.com>
Closes: https://lore.kernel.org/linux-acpi/20250507035124.28071-1-yangyicong@huawei.com/
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Maximilian Heyne <mheyne@amazon.de>
Cc: All applicable <stable@vger.kernel.org> # 7ab4f0e37a0f4: ACPI PPTT: Fix coding mistakes ...
Link: https://patch.msgid.link/20250508023025.1301030-1-jeremy.linton@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
gcc-15: disable '-Wunterminated-string-initialization' entirely for now 2025-04-20T22:30:53+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-04-20T22:30:53+00:00 9d7a0577c9db35c4cc52db90bc415ea248446472 I had left the warning around but as a non-fatal error to get my gcc-15 builds going, but fixed up some of the most annoying warning cases so that it wouldn't be *too* verbose. Because I like the _concept_ of the warning, even if I detested the implementation to shut it up. It turns out the implementation to shut it up is even more broken than I thought, and my "shut up most of the warnings" patch just caused fatal errors on gcc-14 instead. I had tested with clang, but when I upgrade my development environment, I try to do it on all machines because I hate having different systems to maintain, and hadn't realized that gcc-14 now had issues. The ACPI case is literally why I wanted to have a *type* that doesn't trigger the warning (see commit d5d45a7f2619: "gcc-15: make 'unterminated string initialization' just a warning"), instead of marking individual places as "__nonstring". But gcc-14 doesn't like that __nonstring location that shut gcc-15 up, because it's on an array of char arrays, not on one single array: drivers/acpi/tables.c:399:1: error: 'nonstring' attribute ignored on objects of type 'const char[][4]' [-Werror=attributes] 399 | static const char table_sigs[][ACPI_NAMESEG_SIZE] __initconst __nonstring = { | ^~~~~~ and my attempts to nest it properly with a type had failed, because of how gcc doesn't like marking the types as having attributes, only symbols. There may be some trick to it, but I was already annoyed by the bad attribute design, now I'm just entirely fed up with it. I wish gcc had a proper way to say "this type is a *byte* array, not a string". The obvious thing would be to distinguish between "char []" and an explicitly signed "unsigned char []" (as opposed to an implicitly unsigned char, which is typically an architecture-specific default, but for the kernel is universal thanks to '-funsigned-char'). But any "we can typedef a 8-bit type to not become a string just because it's an array" model would be fine. But "__attribute__((nonstring))" is sadly not that sane model. Reported-by: Chris Clayton <chris2553@googlemail.com> Fixes: 4b4bd8c50f48 ("gcc-15: acpi: sprinkle random '__nonstring' crumbles around") Fixes: d5d45a7f2619 ("gcc-15: make 'unterminated string initialization' just a warning") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
I had left the warning around but as a non-fatal error to get my gcc-15
builds going, but fixed up some of the most annoying warning cases so
that it wouldn't be *too* verbose.

Because I like the _concept_ of the warning, even if I detested the
implementation to shut it up.

It turns out the implementation to shut it up is even more broken than I
thought, and my "shut up most of the warnings" patch just caused fatal
errors on gcc-14 instead.

I had tested with clang, but when I upgrade my development environment,
I try to do it on all machines because I hate having different systems
to maintain, and hadn't realized that gcc-14 now had issues.

The ACPI case is literally why I wanted to have a *type* that doesn't
trigger the warning (see commit d5d45a7f2619: "gcc-15: make
'unterminated string initialization' just a warning"), instead of
marking individual places as "__nonstring".

But gcc-14 doesn't like that __nonstring location that shut gcc-15 up,
because it's on an array of char arrays, not on one single array:

  drivers/acpi/tables.c:399:1: error: 'nonstring' attribute ignored on objects of type 'const char[][4]' [-Werror=attributes]
    399 | static const char table_sigs[][ACPI_NAMESEG_SIZE] __initconst __nonstring = {
        | ^~~~~~

and my attempts to nest it properly with a type had failed, because of
how gcc doesn't like marking the types as having attributes, only
symbols.

There may be some trick to it, but I was already annoyed by the bad
attribute design, now I'm just entirely fed up with it.

I wish gcc had a proper way to say "this type is a *byte* array, not a
string".

The obvious thing would be to distinguish between "char []" and an
explicitly signed "unsigned char []" (as opposed to an implicitly
unsigned char, which is typically an architecture-specific default, but
for the kernel is universal thanks to '-funsigned-char').

But any "we can typedef a 8-bit type to not become a string just because
it's an array" model would be fine.

But "__attribute__((nonstring))" is sadly not that sane model.

Reported-by: Chris Clayton <chris2553@googlemail.com>
Fixes: 4b4bd8c50f48 ("gcc-15: acpi: sprinkle random '__nonstring' crumbles around")
Fixes: d5d45a7f2619 ("gcc-15: make 'unterminated string initialization' just a warning")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
gcc-15: acpi: sprinkle random '__nonstring' crumbles around 2025-04-20T18:57:54+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-04-20T18:02:18+00:00 4b4bd8c50f4836ba7d3fcfd6c90f96d2605779fe This is not great: I'd much rather introduce a typedef that is a "ACPI name byte buffer", and use that to mark these special 4-byte ACPI names that do not use NUL termination. But as noted in the previous commit ("gcc-15: make 'unterminated string initialization' just a warning") gcc doesn't actually seem to support that notion, so instead you have to just mark every single array declaration individually. So this is not pretty, but this gets rid of the bulk of the annoying warnings during an allmodconfig build for me. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
This is not great: I'd much rather introduce a typedef that is a "ACPI
name byte buffer", and use that to mark these special 4-byte ACPI names
that do not use NUL termination.

But as noted in the previous commit ("gcc-15: make 'unterminated string
initialization' just a warning") gcc doesn't actually seem to support
that notion, so instead you have to just mark every single array
declaration individually.

So this is not pretty, but this gets rid of the bulk of the annoying
warnings during an allmodconfig build for me.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge branches 'acpi-ec' and 'acpi-button' 2025-04-11T13:50:15+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2025-04-11T13:50:15+00:00 dcc4aca53338d09f7b3272e00aab4a1ff8c69067 Merge updates of the ACPI EC and button drivers for 6.15-rc2: - Add suspend-to-idle EC wakeup quirks for Lenovo Go S (Mario Limonciello). - Prevent ACPI button from sending spurions KEY_POWER events to user space in some cases after a recent update (Mario Limonciello). * acpi-ec: ACPI: EC: Set ec_no_wakeup for Lenovo Go S * acpi-button: ACPI: button: Only send `KEY_POWER` for `ACPI_BUTTON_NOTIFY_STATUS` 
Merge updates of the ACPI EC and button drivers for 6.15-rc2:

 - Add suspend-to-idle EC wakeup quirks for Lenovo Go S (Mario
   Limonciello).

 - Prevent ACPI button from sending spurions KEY_POWER events to user
   space in some cases after a recent update (Mario Limonciello).

* acpi-ec:
  ACPI: EC: Set ec_no_wakeup for Lenovo Go S

* acpi-button:
  ACPI: button: Only send `KEY_POWER` for `ACPI_BUTTON_NOTIFY_STATUS`
ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls 2025-04-07T18:20:56+00:00 Jean-Marc Eurin jmeurin@google.com 2025-04-02T00:15:42+00:00 7ab4f0e37a0f4207e742a8de69be03984db6ebf0 The end of table checks should be done with the structure size, but 2 of the 3 similar calls use the pointer size. Signed-off-by: Jean-Marc Eurin <jmeurin@google.com> Link: https://patch.msgid.link/20250402001542.2600671-1-jmeurin@google.com [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
The end of table checks should be done with the structure size,
but 2 of the 3 similar calls use the pointer size.

Signed-off-by: Jean-Marc Eurin <jmeurin@google.com>
Link: https://patch.msgid.link/20250402001542.2600671-1-jmeurin@google.com
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: EC: Set ec_no_wakeup for Lenovo Go S 2025-04-07T17:59:33+00:00 Mario Limonciello mario.limonciello@amd.com 2025-04-01T13:38:51+00:00 b988685388effd648150aab272533f833a2a70f0 When AC adapter is unplugged or plugged in EC wakes from HW sleep but APU doesn't enter back into HW sleep. The reason this happens is that, when the APU exits HW sleep, the power rails controlled by the EC will power up the TCON. The TCON has a GPIO that will be toggled at this time. The GPIO is not marked as a wakeup source, but the GPIO controller still has an unserviced interrupt. Unserviced interrupts will block entering HW sleep again. Clearing the GPIO doesn't help as the TCON continues to assert it until it's been initialized by i2c-hid. Fixing this would require TCON F/W changes and it's already broken in the wild on production hardware. To avoid triggering this issue add a quirk to avoid letting EC wake up system at all. The power button still works properly on this system. Reported-by: Antheas Kapenekakis <lkml@antheas.dev> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3929 Link: https://github.com/bazzite-org/patchwork/commit/95b93b2852718ee1e808c72e6b1836da4a95fc63 Co-developed-by: Antheas Kapenekakis <lkml@antheas.dev> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20250401133858.1892077-1-superm1@kernel.org [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
When AC adapter is unplugged or plugged in EC wakes from HW sleep but
APU doesn't enter back into HW sleep.

The reason this happens is that, when the APU exits HW sleep, the power
rails controlled by the EC will power up the TCON.  The TCON has a GPIO
that will be toggled at this time.  The GPIO is not marked as a wakeup
source, but the GPIO controller still has an unserviced interrupt.
Unserviced interrupts will block entering HW sleep again. Clearing the
GPIO doesn't help as the TCON continues to assert it until it's been
initialized by i2c-hid.

Fixing this would require TCON F/W changes and it's already broken in
the wild on production hardware.

To avoid triggering this issue add a quirk to avoid letting EC wake
up system at all.  The power button still works properly on this system.

Reported-by: Antheas Kapenekakis <lkml@antheas.dev>
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3929
Link: https://github.com/bazzite-org/patchwork/commit/95b93b2852718ee1e808c72e6b1836da4a95fc63
Co-developed-by: Antheas Kapenekakis <lkml@antheas.dev>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20250401133858.1892077-1-superm1@kernel.org
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: button: Only send `KEY_POWER` for `ACPI_BUTTON_NOTIFY_STATUS` 2025-04-07T17:52:17+00:00 Mario Limonciello mario.limonciello@amd.com 2025-04-04T14:50:22+00:00 a8605b0ed187f53f077a769ce2b52ddb97f3eb42 Commit a7e23ec17feec ("ACPI: button: Install notifier for system events as well") modified the ACPI button behavior to send `ACPI_BUTTON_NOTIFY_WAKE` events. This caused a regression on Dell Optiplex 3040 sending `KEY_POWER` randomly at runtime. Adjust logic so that the `ACPI_BUTTON_NOTIFY_WAKE` event will never send `KEY_POWER`. Fixes: a7e23ec17feec ("ACPI: button: Install notifier for system events as well") Reported-by: Ian Laurie <nixuser@mail.com> Closes: https://lore.kernel.org/linux-acpi/CAJZ5v0hbA6bqxHupTh4NZR-GVSb9M5RL7JSb2yQgvYYJg+z2aQ@mail.gmail.com/T/#md8071e480212201f23e4929607386750d3b6bc13 Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2357044 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Tested-by: Ian Laurie <nixuser@mail.com> Link: https://patch.msgid.link/20250404145034.2608574-1-superm1@kernel.org [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Commit a7e23ec17feec ("ACPI: button: Install notifier for system
events as well") modified the ACPI button behavior to send
`ACPI_BUTTON_NOTIFY_WAKE` events.

This caused a regression on Dell Optiplex 3040 sending `KEY_POWER`
randomly at runtime.

Adjust logic so that the `ACPI_BUTTON_NOTIFY_WAKE` event will never
send `KEY_POWER`.

Fixes: a7e23ec17feec ("ACPI: button: Install notifier for system events as well")
Reported-by: Ian Laurie <nixuser@mail.com>
Closes: https://lore.kernel.org/linux-acpi/CAJZ5v0hbA6bqxHupTh4NZR-GVSb9M5RL7JSb2yQgvYYJg+z2aQ@mail.gmail.com/T/#md8071e480212201f23e4929607386750d3b6bc13
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2357044
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Tested-by: Ian Laurie <nixuser@mail.com>
Link: https://patch.msgid.link/20250404145034.2608574-1-superm1@kernel.org
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge tag 'libnvdimm-for-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 2025-04-03T03:27:18+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-04-03T03:27:18+00:00 447d2d272e4e0c7cd9dfc6aeeadad9d70b3fb1ef Pull libnvdimm updates from Ira Weiny: "Most of the code changes are to remove dead code. The bug fixes are minor, Syzkaller and one for broken devices which are unlikely to be in the field. So no need to backport them. - two patches to remove dead code: nd_attach_ndns() and nd_region_conflict() have not been used since 2017 and 2019 respectively - Fix divide-by-0 if device returns a broken LSA value - Fix Syzkaller reported bug" * tag 'libnvdimm-for-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: libnvdimm/labels: Fix divide error in nd_label_data_init() libnvdimm: Remove unused nd_attach_ndns libnvdimm: Remove unused nd_region_conflict acpi: nfit: fix narrowing conversion in acpi_nfit_ctl 
Pull libnvdimm updates from Ira Weiny:
 "Most of the code changes are to remove dead code.

  The bug fixes are minor, Syzkaller and one for broken devices which
  are unlikely to be in the field. So no need to backport them.

   - two patches to remove dead code: nd_attach_ndns() and
     nd_region_conflict() have not been used since 2017 and 2019
     respectively

   - Fix divide-by-0 if device returns a broken LSA value

   - Fix Syzkaller reported bug"

* tag 'libnvdimm-for-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  libnvdimm/labels: Fix divide error in nd_label_data_init()
  libnvdimm: Remove unused nd_attach_ndns
  libnvdimm: Remove unused nd_region_conflict
  acpi: nfit: fix narrowing conversion in acpi_nfit_ctl