It was previously noted that Kconfig complained about unmet dependencies
when trying to configure skx_edac together with CONFIG_ACPI=n. First fix
for this checked for ACPI when doing
select ACPI_ADXL
but this required stub functions for the case where ACPI wasn't
selected. It also allowed building a driver that didn't actually work
for a system that has non-volatile DIMMs.
Arnd Bergmann pointed out that the right fix is to make EDAC_SKX
"depend on ACPI".
Fixes: a324e9396c ("EDAC, skx: Fix randconfig builds")
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Mauro Carvalho Chehab <mchehab@kernel.org>
CC: linux-edac <linux-edac@vger.kernel.org>
CC: qiuxu.zhuo@intel.com
Link: http://lkml.kernel.org/r/20181106183914.GA26731@agluck-desk
The driver depends on the ADXL component glue and selects it. However,
ADXL itself implicitly depends on ACPI and in nonsensical randconfig
builds like this:
# CONFIG_ACPI is not set
CONFIG_ACPI_ADXL=y
where ACPI is not enabled, the build fails with:
drivers/edac/skx_edac.o: In function `skx_mce_check_error':
skx_edac.c:(.text+0xab): undefined reference to `adxl_decode'
drivers/edac/skx_edac.o: In function `skx_init':
skx_edac.c:(.init.text+0x8bf): undefined reference to `adxl_get_component_names'
make: *** [vmlinux] Error 1
Add stubs for that case so that the build succeeds. CONFIG_ACPI=n
doesn't make any sense for real configurations but this fix will at
least silence randconfig builds.
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Tony Luck <tony.luck@intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
