linux-toradex.git/drivers/acpi, branch v5.11

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

ACPI: scan: Make acpi_bus_get_device() clear return pointer on error

2021-01-20T18:20:20+00:00

Set the acpi_device pointer which acpi_bus_get_device() returns-by-
reference to NULL on errors.

We've recently had 2 cases where callers of acpi_bus_get_device()
did not properly error check the return value, so set the returned-
by-reference acpi_device pointer to NULL, because at least some
callers of acpi_bus_get_device() expect that to be done on errors.

[ rjw: This issue was exposed by commit 71da201f38df ("ACPI: scan:
  Defer enumeration of devices with _DEP lists") which caused it to
  be much more likely to occur on some systems, but the real defect
  had been introduced by an earlier commit. ]

Fixes: 40e7fcb19293 ("ACPI: Add _DEP support to fix battery issue on Asus T100TA")
Fixes: bcfcd409d4db ("usb: split code locating ACPI companion into port and device")
Reported-by: Pierre-Louis Bossart 
Tested-by: Pierre-Louis Bossart 
Diagnosed-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
Cc: All applicable 
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki

ACPI: NFIT: Fix flexible_array.cocci warnings

2021-01-11T20:56:49+00:00

Julia and 0day report:

    Zero-length and one-element arrays are deprecated, see
    Documentation/process/deprecated.rst
    Flexible-array members should be used instead.

However, a straight conversion to flexible arrays yields:

    drivers/acpi/nfit/core.c:2276:4: error: flexible array member in a struct with no named members
    drivers/acpi/nfit/core.c:2287:4: error: flexible array member in a struct with no named members

Instead, just use plain arrays not embedded flexible arrays.

Cc: Denis Efremov 
Reported-by: kernel test robot 
Reported-by: Julia Lawall 
Signed-off-by: Dan Williams