linux.git/drivers/acpi, branch v4.20-rc4

ACPI / platform: Add SMB0001 HID to forbidden_id_list

2018-11-21T12:30:13+00:00

Many HP AMD based laptops contain an SMB0001 device like this:

Device (SMBD)
{
    Name (_HID, "SMB0001")  // _HID: Hardware ID
    Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
    {
        IO (Decode16,
            0x0B20,             // Range Minimum
            0x0B20,             // Range Maximum
            0x20,               // Alignment
            0x20,               // Length
            )
        IRQ (Level, ActiveLow, Shared, )
            {7}
    })
}

The legacy style IRQ resource here causes acpi_dev_get_irqresource() to
be called with legacy=true and this message to show in dmesg:
ACPI: IRQ 7 override to edge, high

This causes issues when later on the AMD0030 GPIO device gets enumerated:

Device (GPIO)
{
    Name (_HID, "AMDI0030")  // _HID: Hardware ID
    Name (_CID, "AMDI0030")  // _CID: Compatible ID
    Name (_UID, Zero)  // _UID: Unique ID
    Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
    {
	Name (RBUF, ResourceTemplate ()
	{
	    Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
	    {
		0x00000007,
	    }
	    Memory32Fixed (ReadWrite,
		0xFED81500,         // Address Base
		0x00000400,         // Address Length
		)
	})
	Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */
    }
}

Now acpi_dev_get_irqresource() gets called with legacy=false, but because
of the earlier override of the trigger-type acpi_register_gsi() returns
-EBUSY (because we try to register the same interrupt with a different
trigger-type) and we end up setting IORESOURCE_DISABLED in the flags.

The setting of IORESOURCE_DISABLED causes platform_get_irq() to call
acpi_irq_get() which is not implemented on x86 and returns -EINVAL.
resulting in the following in dmesg:

amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22
amd_gpio: probe of AMDI0030:00 failed with error -22

The SMB0001 is a "virtual" device in the sense that the only way the OS
interacts with it is through calling a couple of methods to do SMBus
transfers. As such it is weird that it has IO and IRQ resources at all,
because the driver for it is not expected to ever access the hardware
directly.

The Linux driver for the SMB0001 device directly binds to the acpi_device
through the acpi_bus, so we do not need to instantiate a platform_device
for this ACPI device. This commit adds the SMB0001 HID to the
forbidden_id_list, avoiding the instantiating of a platform_device for it.
Not instantiating a platform_device means we will no longer call
acpi_dev_get_irqresource() for the legacy IRQ resource fixing the probe of
the AMDI0030 device failing.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1644013
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198715
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199523
Reported-by: Lukas Kahnert 
Tested-by: Marc 
Cc: All applicable 
Signed-off-by: Hans de Goede 
Signed-off-by: Rafael J. Wysocki

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

2018-11-18T20:21:09+00:00

Pull libnvdimm fixes from Dan Williams:
 "A small batch of fixes for v4.20-rc3.

  The overflow continuation fix addresses something that has been broken
  for several releases. Arguably it could wait even longer, but it's a
  one line fix and this finishes the last of the known address range
  scrub bug reports. The revert addresses a lockdep regression. The unit
  tests are not critical to fix, but no reason to hold this fix back.

  Summary:

   - Address Range Scrub overflow continuation handling has been broken
     since it was initially merged. It was only recently that error
     injection and platform-BIOS support enabled this corner case to be
     exercised.

   - The recent attempt to provide more isolation for the kernel Address
     Range Scrub state machine from userapace initiated sessions
     triggers a lockdep report. Revert and try again at the next merge
     window.

   - Fix a kasan reported buffer overflow in libnvdimm unit test
     infrastrucutre (nfit_test)"

* tag 'libnvdimm-fixes-4.20-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  Revert "acpi, nfit: Further restrict userspace ARS start requests"
  acpi, nfit: Fix ARS overflow continuation
  tools/testing/nvdimm: Fix the array size for dimm devices.

Merge tag 'acpi-4.20-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2018-11-14T21:36:45+00:00

Pull ACPI fix from Rafael Wysocki:
 "Fix a recently introduced build issue in the xpower PMIC driver (Arnd
  Bergmann)"

* tag 'acpi-4.20-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / PMIC: xpower: fix IOSF_MBI dependency

Revert "acpi, nfit: Further restrict userspace ARS start requests"

2018-11-10T17:54:28+00:00

The following lockdep splat results from acquiring the init_mutex in
acpi_nfit_clear_to_send():

 WARNING: possible circular locking dependency detected
 lt-daxdev-error/7216 is trying to acquire lock:
 00000000f694db15 (&acpi_desc->init_mutex){+.+.}, at: acpi_nfit_clear_to_send+0x27/0x80 [nfit]

 but task is already holding lock:
 00000000182298f2 (&nvdimm_bus->reconfig_mutex){+.+.}, at: __nd_ioctl+0x457/0x610 [libnvdimm]

 which lock already depends on the new lock.


 the existing dependency chain (in reverse order) is:

 -> #1 (&nvdimm_bus->reconfig_mutex){+.+.}:
        nvdimm_badblocks_populate+0x41/0x150 [libnvdimm]
        nd_region_notify+0x95/0xb0 [libnvdimm]
        nd_device_notify+0x40/0x50 [libnvdimm]
        ars_complete+0x7f/0xd0 [nfit]
        acpi_nfit_scrub+0xbb/0x410 [nfit]
        process_one_work+0x22b/0x5c0
        worker_thread+0x3c/0x390
        kthread+0x11e/0x140
        ret_from_fork+0x3a/0x50

 -> #0 (&acpi_desc->init_mutex){+.+.}:
        __mutex_lock+0x83/0x980
        acpi_nfit_clear_to_send+0x27/0x80 [nfit]
        __nd_ioctl+0x474/0x610 [libnvdimm]
        nd_ioctl+0xa4/0xb0 [libnvdimm]
        do_vfs_ioctl+0xa5/0x6e0
        ksys_ioctl+0x70/0x80
        __x64_sys_ioctl+0x16/0x20
        do_syscall_64+0x60/0x210
        entry_SYSCALL_64_after_hwframe+0x49/0xbe

New infrastructure is needed to be able to perform this check without
acquiring the lock.

Fixes: 594861215c83 ("acpi, nfit: Further restrict userspace ARS start")
Cc: Dave Jiang 
Signed-off-by: Dan Williams

acpi, nfit: Fix ARS overflow continuation

2018-11-10T17:54:28+00:00

When the platform BIOS is unable to report all the media error records
it requires the OS to restart the scrub at a prescribed location. The
driver detects the overflow condition, but then fails to report it to
the ARS state machine after reaping the records. Propagate -ENOSPC
correctly to continue the ARS operation.

Cc: 
Fixes: 1cf03c00e7c1 ("nfit: scrub and register regions in a workqueue")
Reported-by: Jacek Zloch 
Reviewed-by: Dave Jiang 
Signed-off-by: Dan Williams

ACPI / PMIC: xpower: fix IOSF_MBI dependency

2018-11-08T17:29:33+00:00

We still get a link failure with IOSF_MBI=m when the xpower driver
is built-in:

drivers/acpi/pmic/intel_pmic_xpower.o: In function `intel_xpower_pmic_update_power':
intel_pmic_xpower.c:(.text+0x4f2): undefined reference to `iosf_mbi_block_punit_i2c_access'
intel_pmic_xpower.c:(.text+0x5e2): undefined reference to `iosf_mbi_unblock_punit_i2c_access'

This makes the dependency stronger, so we can only build when IOSF_MBI
is built-in.

Fixes: 6a9b593d4b6f (ACPI / PMIC: xpower: Add depends on IOSF_MBI to Kconfig entry)
Signed-off-by: Arnd Bergmann 
Signed-off-by: Rafael J. Wysocki

acpi/nfit, x86/mce: Validate a MCE's address before using it

2018-11-06T18:13:26+00:00

The NFIT machine check handler uses the physical address from the mce
structure, and compares it against information in the ACPI NFIT table
to determine whether that location lies on an NVDIMM. The mce->addr
field however may not always be valid, and this is indicated by the
MCI_STATUS_ADDRV bit in the status field.

Export mce_usable_address() which already performs validation for the
address, and use it in the NFIT handler.

Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Reported-by: Robert Elliott 
Signed-off-by: Vishal Verma 
Signed-off-by: Borislav Petkov 
CC: Arnd Bergmann 
Cc: Dan Williams 
CC: Dave Jiang 
CC: elliott@hpe.com
CC: "H. Peter Anvin" 
CC: Ingo Molnar 
CC: Len Brown 
CC: linux-acpi@vger.kernel.org
CC: linux-edac 
CC: linux-nvdimm@lists.01.org
CC: Qiuxu Zhuo 
CC: "Rafael J. Wysocki" 
CC: Ross Zwisler 
CC: stable 
CC: Thomas Gleixner 
CC: Tony Luck 
CC: x86-ml 
CC: Yazen Ghannam 
Link: http://lkml.kernel.org/r/20181026003729.8420-2-vishal.l.verma@intel.com

acpi/nfit, x86/mce: Handle only uncorrectable machine checks

2018-11-06T18:13:10+00:00

The MCE handler for nfit devices is called for memory errors on a
Non-Volatile DIMM and adds the error location to a 'badblocks' list.
This list is used by the various NVDIMM drivers to avoid consuming known
poison locations during IO.

The MCE handler gets called for both corrected and uncorrectable errors.
Until now, both kinds of errors have been added to the badblocks list.
However, corrected memory errors indicate that the problem has already
been fixed by hardware, and the resulting interrupt is merely a
notification to Linux.

As far as future accesses to that location are concerned, it is
perfectly fine to use, and thus doesn't need to be included in the above
badblocks list.

Add a check in the nfit MCE handler to filter out corrected mce events,
and only process uncorrectable errors.

Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Reported-by: Omar Avelar 
Signed-off-by: Vishal Verma 
Signed-off-by: Borislav Petkov 
CC: Arnd Bergmann 
CC: Dan Williams 
CC: Dave Jiang 
CC: elliott@hpe.com
CC: "H. Peter Anvin" 
CC: Ingo Molnar 
CC: Len Brown 
CC: linux-acpi@vger.kernel.org
CC: linux-edac 
CC: linux-nvdimm@lists.01.org
CC: Qiuxu Zhuo 
CC: "Rafael J. Wysocki" 
CC: Ross Zwisler 
CC: stable 
CC: Thomas Gleixner 
CC: Tony Luck 
CC: x86-ml 
CC: Yazen Ghannam 
Link: http://lkml.kernel.org/r/20181026003729.8420-1-vishal.l.verma@intel.com

Merge tag 'pwm/for-4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm

2018-11-02T18:22:45+00:00

Pull pwm updates from Thierry Reding:
 "This series contains a number of improvements to existing drivers,
  such as LPSS. Some drivers, such as renesas-tpu and rcar get support
  for more SoC generations. To round things off this fixes an issue with
  the sysfs interface"

* tag 'pwm/for-4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
  pwm: lpss: Only set update bit if we are actually changing the settings
  pwm: lpss: Force runtime-resume on suspend on Cherry Trail
  pwm: Enable TI ECAP driver for ARCH_K3
  dt-bindings: pwm: tiecap: Add TI AM654 SoC specific compatible
  dt-bindings: pwm: rcar: Add r8a774a1 support
  pwm: Send a uevent on the pwmchip device upon channel sysfs (un)export
  Revert "pwm: Set class for exported channels in sysfs"
  dt-bindings: pwm: renesas-tpu: Document r8a7744 support
  dt-bindings: pwm: rcar: Add r8a7744 support
  dt-bindings: pwm: renesas: tpu: Document R8A779{7|8}0 bindings
  dt-bindings: pwm: renesas: pwm-rcar: Document R8A779{7|8}0 bindings
  dt-bindings: pwm: renesas: tpu: Fix "compatible" prop description
  pwm: Use SPDX identifier for Renesas drivers
  pwm: lpss: Add get_state callback
  pwm: lpss: Release runtime-pm reference from the driver's remove callback
  pwm: lpss: Check PWM powerstate after resume on Cherry Trail devices
  pwm: lpss: Move struct pwm_lpss_chip definition to the header file
  pwm: lpss: Add ACPI HID for second PWM controller on Cherry Trail devices
  ACPI / PM: Export acpi_device_get_power() for use by modular build drivers
  pwm: tegra: Remove gratuituous blank line

mm/memory_hotplug: make add_memory() take the device_hotplug_lock

2018-10-31T15:54:17+00:00

add_memory() currently does not take the device_hotplug_lock, however
is aleady called under the lock from
	arch/powerpc/platforms/pseries/hotplug-memory.c
	drivers/acpi/acpi_memhotplug.c
to synchronize against CPU hot-remove and similar.

In general, we should hold the device_hotplug_lock when adding memory to
synchronize against online/offline request (e.g.  from user space) - which
already resulted in lock inversions due to device_lock() and
mem_hotplug_lock - see 30467e0b3be ("mm, hotplug: fix concurrent memory
hot-add deadlock").  add_memory()/add_memory_resource() will create memory
block devices, so this really feels like the right thing to do.

Holding the device_hotplug_lock makes sure that a memory block device
can really only be accessed (e.g. via .online/.state) from user space,
once the memory has been fully added to the system.

The lock is not held yet in
	drivers/xen/balloon.c
	arch/powerpc/platforms/powernv/memtrace.c
	drivers/s390/char/sclp_cmd.c
	drivers/hv/hv_balloon.c
So, let's either use the locked variants or take the lock.

Don't export add_memory_resource(), as it once was exported to be used by
XEN, which is never built as a module.  If somebody requires it, we also
have to export a locked variant (as device_hotplug_lock is never
exported).

Link: http://lkml.kernel.org/r/20180925091457.28651-3-david@redhat.com
Signed-off-by: David Hildenbrand 
Reviewed-by: Pavel Tatashin 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Rashmica Gupta 
Reviewed-by: Oscar Salvador 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Greg Kroah-Hartman 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Nathan Fontenot 
Cc: John Allen 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Joonsoo Kim 
Cc: Vlastimil Babka 
Cc: Mathieu Malaterre 
Cc: Pavel Tatashin 
Cc: YASUAKI ISHIMATSU 
Cc: Balbir Singh 
Cc: Haiyang Zhang 
Cc: Heiko Carstens 
Cc: Jonathan Corbet 
Cc: Kate Stewart 
Cc: "K. Y. Srinivasan" 
Cc: Martin Schwidefsky 
Cc: Michael Neuling 
Cc: Philippe Ombredanne 
Cc: Stephen Hemminger 
Cc: Thomas Gleixner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds