EDAC, dsm_edac: Wrap ACPI DSM methods for address translation
Luck, Tony
maintainerPATCH 4/5 EDAC, dsm_edac: Wrap ACPI DSM methods for address translation
Rafael: You'd become the deciding maintainer if we follow this new direction.
Quoted 2 lines · Borislav Petkov
So this sounds like
drivers/acpi/acpi_extlog.cwhich you guys did. Is that thing being abandoned now too, for yet another thing?
It's like acpi_extlog.c in that it uses an ACPI DSM. Also related to error reporting. No, we aren't abandoning extlog, but it seems that fewer OEMs than we hoped are adopting eMCA and implementing the extended log in their BIOS.
Quoted 3 lines
And that extlog thing is under
drivers/acpi/. So even if the DSM stuff is *maybe* going to be part of the ACPI spec, I believedrivers/acpi/is where it should go. As in: preparing to become part of ACPI :-)
That's a good argment for moving it there.
Quoted 2 lines
But, there's another aspect: is this DSM interface going to be used only by EDAC or some other subsystems? (It seems so.)
Unclear who else might want to use this. I spoke to an internal validation guy (who is the person who mostly came up with this DSM idea). He has some out-of-tree driver that can call into any DSM. So it is unclear whether he'd want to use whatever we write. But if there are going to be other users someday, then the interface should be less EDAC focussed.
Quoted 5 lines
Because if it is going to be used by EDAC only and EDAC drivers will reg/unreg with it, then I guess making it part of the EDAC core, would probably be more fitting. Something like
drivers/edac/dsm.cand then you don't have to have another module which needs to sync with the *actual* EDAC module...
The module syning part is painful/ugly. Making this built-in would be far prettier (more maintainable).
Quoted 2 lines
Practically, this is going to be enabled on 99.9% of the boxes so making it part of the core is, I guess, just as well.
So I dropped Qiuxu's code into a blender and ran it on high for a few minutes. Below is an RFC patch (compiles, but otherwise untested) to see what things would looks like with a built in ACPI block with no registrations to EDAC core, or other stuff that is specific to the EDAC usage model.
When it finds the BIOS support this, it provides three EXPORT objects:
1) A count of how many address components are provided.
2) A "char **" pointer to the strings for those components
3) A function that takes a system address, and fills in an array of component values.
The final patch to update skx_edac.c would have to be updated for these new interface options. But that shouldn't be too hard.
Here's the patch for the new ACPI ADXL code:
---
drivers/acpi/Kconfig | 10 +++ drivers/acpi/Makefile | 3 + drivers/acpi/acpi_adxl.c | 156 +++++++++++++++++++++++++++++++++++++++ include/linux/adxl.h | 18 +++++ 4 files changed, 187 insertions(+) create mode 100644 drivers/acpi/acpi_adxl.c create mode 100644 include/linux/adxl.h
drivers/acpi/Kconfig +10 -0
@@ -498,6 +498,16 @@ config ACPI_EXTLOG driver adds support for that functionality with corresponding tracepoint which carries that information to userspace. +config ACPI_ADXL + bool "Physical address to DIMM address translation" + def_bool n + help + Enable interface that calls into BIOS using a DSM (device + specific method) to convert system physical addresses + to DIMM (socket, channel, rank, dimm, etc.). + Only available on some servers. + Used by newer EDAC drivers. + menuconfig PMIC_OPREGION bool "PMIC (Power Management Integrated Circuit) operation region support" help
drivers/acpi/Makefile +3 -0
@@ -61,6 +61,9 @@ acpi-$(CONFIG_ACPI_LPIT) += acpi_lpit.o acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o +# Address translation +acpi-$(CONFIG_ACPI_ADXL) += acpi_adxl.o + # These are (potentially) separate modules # IPMI may be used by other drivers, so it has to initialise before them
drivers/acpi/acpi_adxl.c new file +156 -0
156 lines not on this page · raw message
include/linux/adxl.h new file +18 -0
@@ -0,0 +1,18 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* +* Address translation interface via ACPI DSM. +* Copyright (C) 2018 Intel Corporation +*/ + +#ifdef CONFIG_ACPI_ADXL +int adxl_count; +char **adxl_component_names; +int adxl_decode (u64 addr,u64 component_values[]); +#else +#define adxl_count 0 +#define adxl_component_names NULL +static inline int adxl_decode (u64 addr,u64 component_values[]) +{ +return -EOPNOTSUPP ; +} +#endif