linux-stable.git/drivers/acpi, branch v5.4.78

ACPI: NFIT: Fix comparison to '-ENXIO'

2020-11-10T11:37:31+00:00

[ Upstream commit 85f971b65a692b68181438e099b946cc06ed499b ]

Initial value of rc is '-ENXIO', and we should
use the initial value to check it.

Signed-off-by: Zhang Qilong 
Reviewed-by: Pankaj Gupta 
Reviewed-by: Vishal Verma 
[ rjw: Subject edit ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI: EC: PM: Drop ec_no_wakeup check from acpi_ec_dispatch_gpe()

2020-11-05T10:43:25+00:00

commit e0e9ce390d7bc6a705653d4a8aa4ea92c9a65e53 upstream.

It turns out that in some cases there are EC events to flush in
acpi_ec_dispatch_gpe() even though the ec_no_wakeup kernel parameter
is set and the EC GPE is disabled while sleeping, so drop the
ec_no_wakeup check that prevents those events from being processed
from acpi_ec_dispatch_gpe().

Reported-by: Todd Brandt 
Cc: 5.4+  # 5.4+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: EC: PM: Flush EC work unconditionally after wakeup

2020-11-05T10:43:25+00:00

commit 5e92442bb4121562231e6daf8a2d1306cb5f8805 upstream.

Commit 607b9df63057 ("ACPI: EC: PM: Avoid flushing EC work when EC
GPE is inactive") has been reported to cause some power button wakeup
events to be missed on some systems, so modify acpi_ec_dispatch_gpe()
to call acpi_ec_flush_work() unconditionally to effectively reverse
the changes made by that commit.

Also note that the problem which prompted commit 607b9df63057 is not
reproducible any more on the affected machine.

Fixes: 607b9df63057 ("ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive")
Reported-by: Raymond Tan 
Cc: 5.4+  # 5.4+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: debug: don't allow debugging when ACPI is disabled

2020-11-05T10:43:25+00:00

commit 0fada277147ffc6d694aa32162f51198d4f10d94 upstream.

If ACPI is disabled then loading the acpi_dbg module will result in the
following splat when lock debugging is enabled.

  DEBUG_LOCKS_WARN_ON(lock->magic != lock)
  WARNING: CPU: 0 PID: 1 at kernel/locking/mutex.c:938 __mutex_lock+0xa10/0x1290
  Kernel panic - not syncing: panic_on_warn set ...
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc8+ #103
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   dump_backtrace+0x0/0x4d8
   show_stack+0x34/0x48
   dump_stack+0x174/0x1f8
   panic+0x360/0x7a0
   __warn+0x244/0x2ec
   report_bug+0x240/0x398
   bug_handler+0x50/0xc0
   call_break_hook+0x160/0x1d8
   brk_handler+0x30/0xc0
   do_debug_exception+0x184/0x340
   el1_dbg+0x48/0xb0
   el1_sync_handler+0x170/0x1c8
   el1_sync+0x80/0x100
   __mutex_lock+0xa10/0x1290
   mutex_lock_nested+0x6c/0xc0
   acpi_register_debugger+0x40/0x88
   acpi_aml_init+0xc4/0x114
   do_one_initcall+0x24c/0xb10
   kernel_init_freeable+0x690/0x728
   kernel_init+0x20/0x1e8
   ret_from_fork+0x10/0x18

This is because acpi_debugger.lock has not been initialized as
acpi_debugger_init() is not called when ACPI is disabled.  Fail module
loading to avoid this and any subsequent problems that might arise by
trying to debug AML when ACPI is disabled.

Fixes: 8cfb0cdf07e2 ("ACPI / debugger: Add IO interface to access debugger functionalities")
Reviewed-by: Hanjun Guo 
Signed-off-by: Jamie Iles 
Cc: 4.10+  # 4.10+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: video: use ACPI backlight for HP 635 Notebook

2020-11-05T10:43:25+00:00

commit b226faab4e7890bbbccdf794e8b94276414f9058 upstream.

The default backlight interface is AMD's radeon_bl0 which does not
work on this system, so use the ACPI backlight interface on it
instead.

BugLink: https://bugs.launchpad.net/bugs/1894667
Cc: All applicable 
Signed-off-by: Alex Hung 
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / extlog: Check for RDMSR failure

2020-11-05T10:43:24+00:00

commit 7cecb47f55e00282f972a1e0b09136c8cd938221 upstream.

extlog_init() uses rdmsrl() to read an MSR, which on older CPUs
provokes a error message at boot:

    unchecked MSR access error: RDMSR from 0x179 at rIP: 0xcd047307 (native_read_msr+0x7/0x40)

Use rdmsrl_safe() instead, and return -ENODEV if it fails.

Reported-by: jim@photojim.ca
References: https://bugs.debian.org/971058
Cc: All applicable 
Signed-off-by: Ben Hutchings 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: button: fix handling lid state changes when input device closed

2020-11-05T10:43:24+00:00

commit 21988a8e51479ceffe7b0568b170effabb708dfe upstream.

The original intent of 84d3f6b76447 was to delay evaluating lid state until
all drivers have been loaded, with input device being opened from userspace
serving as a signal for this condition. Let's ensure that state updates
happen even if userspace closed (or in the future inhibited) input device.

Note that if we go through suspend/resume cycle we assume the system has
been fully initialized even if LID input device has not been opened yet.

This has a side-effect of fixing access to input->users outside of
input->mutex protections by the way of eliminating said accesses and using
driver private flag.

Fixes: 84d3f6b76447 ("ACPI / button: Delay acpi_lid_initialize_state() until first user space open")
Signed-off-by: Dmitry Torokhov 
Reviewed-by: Hans de Goede 
Cc: 4.15+  # 4.15+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: HMAT: Fix handling of changes from ACPI 6.2 to ACPI 6.3

2020-11-05T10:43:19+00:00

[ Upstream commit 2c5b9bde95c96942f2873cea6ef383c02800e4a8 ]

In ACPI 6.3, the Memory Proximity Domain Attributes Structure
changed substantially.  One of those changes was that the flag
for "Memory Proximity Domain field is valid" was deprecated.

This was because the field "Proximity Domain for the Memory"
became a required field and hence having a validity flag makes
no sense.

So the correct logic is to always assume the field is there.
Current code assumes it never is.

Signed-off-by: Jonathan Cameron 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI: Add out of bounds and numa_off protections to pxm_to_node()

2020-11-05T10:43:18+00:00

[ Upstream commit 8a3decac087aa897df5af04358c2089e52e70ac4 ]

The function should check the validity of the pxm value before using
it to index the pxm_to_node_map[] array.

Whilst hardening this code may be good in general, the main intent
here is to enable following patches that use this function to replace
acpi_map_pxm_to_node() for non SRAT usecases which should return
NO_NUMA_NODE for PXM entries not matching with those in SRAT.

Signed-off-by: Jonathan Cameron 
Reviewed-by: Barry Song 
Reviewed-by: Hanjun Guo 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI: Always build evged in

2020-10-17T08:11:22+00:00

commit ac36d37e943635fc072e9d4f47e40a48fbcdb3f0 upstream.

Although the Generic Event Device is a Hardware-reduced
platfom device in principle, it should not be restricted to
ACPI_REDUCED_HARDWARE_ONLY.

Kernels supporting both fixed and hardware-reduced ACPI platforms
should be able to probe the GED when dynamically detecting that a
platform is hardware-reduced. For that, the driver must be
unconditionally built in.

Signed-off-by: Arjan van de Ven 
Signed-off-by: Samuel Ortiz 
Signed-off-by: Rafael J. Wysocki 
Cc: Vishnu Rangayyan 
Signed-off-by: Greg Kroah-Hartman