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

ACPI: configfs: add missing check after configfs_register_default_group()

2021-03-04T11:15:17+00:00

commit 67e40054de86aae520ddc2a072d7f6951812a14f upstream.

A list_add corruption is reported by Hulk Robot like this:
==============
list_add corruption.
Call Trace:
link_obj+0xc0/0x1c0
link_group+0x21/0x140
configfs_register_subsystem+0xdb/0x380
acpi_configfs_init+0x25/0x1000 [acpi_configfs]
do_one_initcall+0x149/0x820
do_init_module+0x1ef/0x720
load_module+0x35c8/0x4380
__do_sys_finit_module+0x10d/0x1a0
do_syscall_64+0x34/0x80

It's because of the missing check after configfs_register_default_group,
where configfs_unregister_subsystem should be called once failure.

Fixes: 612bd01fc6e0 ("ACPI: add support for loading SSDTs via configfs")
Reported-by: Hulk Robot 
Suggested-by: Hanjun Guo 
Signed-off-by: Qinglang Miao 
Cc: 4.10+  # 4.10+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: property: Fix fwnode string properties matching

2021-03-04T11:15:17+00:00

commit e1e6bd2995ac0e1ad0c2a2d906a06f59ce2ed293 upstream.

Property matching does not work for ACPI fwnodes if the value of the
given property is not represented as a package in the _DSD package
containing it.  For example, the "compatible" property in the _DSD
below

  Name (_DSD, Package () {
    ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
    Package () {
      Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
    }
  })

will not be found by fwnode_property_match_string(), because the ACPI
code handling device properties does not regard the single value as a
"list" in that case.

Namely, fwnode_property_match_string() invoked to match a given
string property value first calls fwnode_property_read_string_array()
with the last two arguments equal to NULL and 0, respectively, in
order to count the items in the value of the given property, with the
assumption that this value may be an array.  For ACPI fwnodes, that
operation is carried out by acpi_node_prop_read() which calls
acpi_data_prop_read() for this purpose.  However, when the return
(val) pointer is NULL, that function only looks for a property whose
value is a package without checking the single-value case at all.

To fix that, make acpi_data_prop_read() check the single-value
case if its return pointer argument is NULL and modify
acpi_data_prop_read_single() handling that case to attempt to
read the value of the property if the return pointer is NULL
and return 1 if that succeeds.

Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files")
Reported-by: Calvin Johnson 
Cc: 4.13+  # 4.13+
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Sakari Ailus 
Reviewed-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

Revert "ACPICA: Interpreter: fix memory leak by using existing buffer"

2021-02-08T12:46:53+00:00

This reverts commit 32cf1a12cad43358e47dac8014379c2f33dfbed4.

The 'exisitng buffer' in this case is the firmware provided table, and
we should not modify that in place. This fixes a crash on arm64 with
initrd table overrides, in which case the DSDT is not mapped with
read/write permissions.

Reported-by: Shawn Guo 
Signed-off-by: Ard Biesheuvel 
Tested-by: Shawn Guo 
Signed-off-by: Rafael J. Wysocki

Merge tag 'libnvdimm-fixes-5.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm

2021-02-07T18:45:26+00:00

Pull libnvdimm fixes from Dan Williams:
 "A fix for a crash scenario that has been present since the initial
  merge, a minor regression in sysfs attribute visibility, and a fix for
  some flexible array warnings.

  The bulk of this pull is an update to the libnvdimm unit test
  infrastructure to test non-ACPI platforms. Given there is zero
  regression risk for test updates, and the tests enable validation of
  bits headed towards the next merge window, I saw no reason to hold the
  new tests back. Santosh originally submitted this before the v5.11
  window opened.

  Summary:

   - Fix a crash when sysfs accesses race 'dimm' driver probe/remove.

   - Fix a regression in 'resource' attribute visibility necessary for
     mapping badblocks and other physical address interrogations.

   - Fix some flexible array warnings

   - Expand the unit test infrastructure for non-ACPI platforms"

* tag 'libnvdimm-fixes-5.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  libnvdimm/dimm: Avoid race between probe and available_slots_show()
  ndtest: Add papr health related flags
  ndtest: Add nvdimm control functions
  ndtest: Add regions and mappings to the test buses
  ndtest: Add dimm attributes
  ndtest: Add dimms to the two buses
  ndtest: Add compatability string to treat it as PAPR family
  testing/nvdimm: Add test module for non-nfit platforms
  libnvdimm/namespace: Fix visibility of namespace resource attribute
  libnvdimm/pmem: Remove unused header
  ACPI: NFIT: Fix flexible_array.cocci warnings

ACPI: scan: Fix battery devices sometimes never binding

2021-02-01T17:53:49+00:00

With the new 2 step scanning process, which defers instantiating some
ACPI-devices based on their _DEP to the second step, the following may
happen:

1. During the first acpi_walk_namespace(acpi_bus_check_add) call
   acpi_scan_check_dep() gets called on the Battery ACPI dev handle and
   adds one or more deps for this handle to the acpi_dep_list

2. During the first acpi_bus_attach() call one or more of the suppliers of
   these deps get their driver attached and
   acpi_walk_dep_device_list(supplier_handle) gets called.

   At this point acpi_bus_get_device(dep->consumer) get called,
   but since the battery has DEPs it has not been instantiated during the
   first acpi_walk_namespace(acpi_bus_check_add), so the
   acpi_bus_get_device(dep->consumer) call fails.

   Before this commit, acpi_walk_dep_device_list() would now continue
   *without* removing the acpi_dep_data entry for this supplier,consumer
   pair from the acpi_dep_list.

3. During the second acpi_walk_namespace(acpi_bus_check_add) call
   an acpi_device gets instantiated for the battery and
   acpi_scan_dep_init() gets called to initialize its dep_unmet val.

   Before this commit, the dep_unmet count would include DEPs for
   suppliers for which acpi_walk_dep_device_list(supplier_handle)
   has already been called, so it will never become 0 and the
   ACPI battery driver will never get attached / bind.

Fix the ACPI battery driver never binding in this scenario by making
acpi_walk_dep_device_list() always remove matching acpi_dep_data
entries independent of the acpi_bus_get_device(dep->consumer) call
succeeding or not.

Fixes: 71da201f38df ("ACPI: scan: Defer enumeration of devices with _DEP lists")
Signed-off-by: Hans de Goede 
Signed-off-by: Rafael J. Wysocki

Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

2021-01-29T21:59:24+00:00

Pull arm64 fixes from Catalin Marinas:

 - Fix the virt_addr_valid() returning true for < PAGE_OFFSET addresses.

 - Do not blindly trust the DMA masks from ACPI/IORT.

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  ACPI/IORT: Do not blindly trust DMA masks from firmware
  arm64: Fix kernel address detection of __is_lm_address()

Merge branch 'acpi-sysfs'

2021-01-29T15:28:48+00:00

* acpi-sysfs:
  ACPI: sysfs: Prefer "compatible" modalias

ACPI/IORT: Do not blindly trust DMA masks from firmware

2021-01-27T12:26:24+00:00

Address issue observed on real world system with suboptimal IORT table
where DMA masks of PCI devices would get set to 0 as result.

iort_dma_setup() would query the root complex'/named component IORT
entry for a DMA mask, and use that over the one the device has been
configured with earlier.

Ideally we want to use the minimum mask of what the IORT contains for
the root complex and what the device was configured with.

Fixes: 5ac65e8c8941 ("ACPI/IORT: Support address size limit for root complexes")
Signed-off-by: Moritz Fischer 
Reviewed-by: Robin Murphy 
Acked-by: Lorenzo Pieralisi 
Link: https://lore.kernel.org/r/20210122012419.95010-1-mdf@kernel.org
Signed-off-by: Catalin Marinas

ACPI: thermal: Do not call acpi_thermal_check() directly

2021-01-25T16:20:16+00:00

Calling acpi_thermal_check() from acpi_thermal_notify() directly
is problematic if _TMP triggers Notify () on the thermal zone for
which it has been evaluated (which happens on some systems), because
it causes a new acpi_thermal_notify() invocation to be queued up
every time and if that takes place too often, an indefinite number of
pending work items may accumulate in kacpi_notify_wq over time.

Besides, it is not really useful to queue up a new invocation of
acpi_thermal_check() if one of them is pending already.

For these reasons, rework acpi_thermal_notify() to queue up a thermal
check instead of calling acpi_thermal_check() directly and only allow
one thermal check to be pending at a time.  Moreover, only allow one
acpi_thermal_check_fn() instance at a time to run
thermal_zone_device_update() for one thermal zone and make it return
early if it sees other instances running for the same thermal zone.

While at it, fold acpi_thermal_check() into acpi_thermal_check_fn(),
as it is only called from there after the other changes made here.

[This issue appears to have been exposed by commit 6d25be5782e4
 ("sched/core, workqueues: Distangle worker accounting from rq
 lock"), but it is unclear why it was not visible earlier.]

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208877
Reported-by: Stephen Berman 
Diagnosed-by: Sebastian Andrzej Siewior 
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Sebastian Andrzej Siewior 
Tested-by: Stephen Berman 
Cc: All applicable

ACPI: sysfs: Prefer "compatible" modalias

2021-01-25T16:06:14+00:00

Commit 8765c5ba1949 ("ACPI / scan: Rework modalias creation when
"compatible" is present") may create two "MODALIAS=" in one uevent
file if specific conditions are met.

This breaks systemd-udevd, which assumes each "key" in one uevent file
to be unique. The internal implementation of systemd-udevd overwrites
the first MODALIAS with the second one, so its kmod rule doesn't load
the driver for the first MODALIAS.

So if both the ACPI modalias and the OF modalias are present, use the
latter to ensure that there will be only one MODALIAS.

Link: https://github.com/systemd/systemd/pull/18163
Suggested-by: Mika Westerberg 
Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present")
Signed-off-by: Kai-Heng Feng 
Reviewed-by: Mika Westerberg 
Reviewed-by: Greg Kroah-Hartman 
Cc: 4.1+  # 4.1+
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki