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 <arnd@arndb.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

This is necessary to avoid compilation issues on non x86 systems (where the
asm/iosf_mbi.h header is not available) and on x86 systems in case IOSF_MBI
support is not enabled there.

Note that the AXP288 PMIC is connected through the LPSS i2c controller, so
either we have IOSF_MBI support selected through the X86_INTEL_LPSS option,
or we have a kernel where the OpRegion will never work anyways.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Pull EDAC updates from Borislav Petkov:
 "The EDAC tree was busier than usual this cycle as the shortlog below
  shows.

  Also, this pull request is carrying an ACPI DSM driver which is used
  to ask the platform to supply the DIMM location of a reported hardware
  error and thus simplify all the EDAC logic when trying to map the
  error address to the respective DIMM.

  Core EDAC updates:

   - amd64_edac: AMD family 0x17, models 0x10-0x2f support (Michael Jin)
     Hygon Dhyana support (Pu Wen)

   - sb_edac: New maintainer + fixes (Tony Luck) Error reporting
     improvements and fixes (Qiuxu Zhuo)

   - ghes_edac: SMBIOS handle type 17 for DIMM locating and per-DIMM
     error accounting (Fan Wu)

   - altera_edac: Stratix10 support and refactoring (Thor Thayer)

  Out of tree addition:

   - acpi_adxl: Address Translation interface using an ACPI DSM (Tony
     Luck)

   - the usual amount of other misc fixes and cleanups all over"

* tag 'edac_for_4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp: (22 commits)
  ACPI/ADXL: Add address translation interface using an ACPI DSM
  EDAC, thunderx: Fix memory leak in thunderx_l2c_threaded_isr()
  EDAC, skx_edac: Fix logical channel intermediate decoding
  EDAC, {i7core,sb,skx}_edac: Fix uncorrected error counting
  EDAC, altera: Work around int-to-pointer-cast warnings
  EDAC, amd64: Add Hygon Dhyana support
  EDAC: Raise the maximum number of memory controllers
  arm64: dts: stratix10: Add peripheral EDAC nodes
  EDAC, altera: Add Stratix10 peripheral support
  EDAC, altera: Merge Stratix10 into the Arria10 SDRAM probe routine
  arm64: dts: stratix10: Add SDRAM node
  EDAC, altera: Combine Stratix10 and Arria10 probe functions
  arm64: dts: stratix10: Additions to EDAC System Manager
  EDAC, i7core: Remove set but not used variable pvt
  EDAC, ghes: Use CPER module handles to locate DIMMs
  EDAC: Correct DIMM capacity unit symbol
  EDAC, sb_edac: Fix signedness bugs in *_get_ha() functions
  EDAC, sb_edac: Fix reporting for patrol scrubber errors
  EDAC, sb_edac: Return early on ADDRV bit and address type test
  MAINTAINERS: Update maintainer for drivers/edac/sb_edac.c
  ...

Some new Intel servers provide an interface so that the OS can ask the
BIOS to translate a system physical address to a memory address (socket,
memory controller, channel, rank, dimm, etc.). This is useful for EDAC
drivers that want to take the address of an error reported in a machine
check bank and let the user know which DIMM may need to be replaced.

Specification for this interface is available at:

  https://cdrdv2.intel.com/v1/dl/getContent/603354

 [ Based on earlier code by Qiuxu Zhuo <qiuxu.zhuo@intel.com>. ]

 [ bp: Make the first pr_info() in adxl_init() pr_debug() so that it
   doesn't pollute every dmesg. ]

Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
CC: Len Brown <lenb@kernel.org>
CC: linux-acpi@vger.kernel.org
CC: linux-edac@vger.kernel.org
Link: http://lkml.kernel.org/r/20181015202620.23610-1-tony.luck@intel.com

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

    ...
    One side effect of (and the main motivation for) this change is making
    the following two definitions behave exactly the same:

        config FOO
                bool

        config FOO
                bool
                default n

    With this change, neither of these will generate a
    '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
    That might make it clearer to people that a bare 'default n' is
    redundant.
    ...

Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

My fix for a recursive Kconfig dependency caused another issue where the
ACPI specific options end up in the top-level menu in 'menuconfig'. This
was an unintended side-effect of having a silent option between
'menuconfig ACPI' and 'if ACPI'.

Moving the ARCH_SUPPORTS_ACPI symbol ahead of the ACPI menu solves that
problem and restores the previous presentation.

Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Fixes: 2c870e61132c (arm64: fix ACPI dependencies)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Kconfig reports a warning on x86 builds after the ARM64 dependency
was added.

drivers/acpi/Kconfig:6:error: recursive dependency detected!
drivers/acpi/Kconfig:6:       symbol ACPI depends on EFI

This rephrases the dependency to keep the ARM64 details out of the
shared Kconfig file, so Kconfig no longer gets confused by it.

For consistency, all three architectures that support ACPI now
select ARCH_SUPPORTS_ACPI in exactly the configuration in which
they allow it. We still need the 'default x86', as each one
wants a different default: default-y on x86, default-n on arm64,
and always-y on ia64.

Fixes: 5bcd44083a08 ("drivers: acpi: add dependency of EFI for arm64")
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>

As Ard suggested, CONFIG_ACPI && !CONFIG_EFI doesn't make sense on arm64,
while CONFIG_ACPI and CONFIG_CPU_BIG_ENDIAN doesn't make sense either.

As CONFIG_EFI already has a dependency of !CONFIG_CPU_BIG_ENDIAN, it is
good enough to add a dependency of CONFIG_EFI to avoid any useless
combination of configuration.

This bug, reported by Will, will be revealed when my patch series,
"arm64: kexec,kdump: fix boot failures on acpi-only system," is applied
and the kernel is built under allmodconfig.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>

Now that we have a PPTT parser, in preparation for its use
on arm64, lets build it.

Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

* acpi-osi:
  ACPI / OSI: Add OEM _OSI strings to disable NVidia RTD3

* acpi-scan:
  ACPI / scan: Send change uevent with offine environmental data

* acpi-tad:
  ACPI: Add Time and Alarm Device (TAD) driver

* acpi-video:
  ACPI / video: Add quirk to force acpi-video backlight on Samsung 670Z5E

* acpi-misc:
  ACPI / Kconfig: Update ACPI_PROCFS_POWER help text