[4/5] EDAC, dsm_edac: Wrap ACPI DSM methods for address translation

[Borislav Petkov <bp@alien8.de>]

On Fri, Oct 05, 2018 at 03:25:57PM -0700, Luck, Tony wrote:
> 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.

Ok, but what is the difference with this DSM thing and why would OEMs
use that? They get it for free from you? Or?

> The module syning part is painful/ugly.  Making this built-in would
> be far prettier (more maintainable).

Yap.

> > 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.

Looks nice and clean to me.

...

> diff --git a/drivers/acpi/acpi_adxl.c b/drivers/acpi/acpi_adxl.c
> new file mode 100644
> index 000000000000..a0e026680c3d
> --- /dev/null
> +++ b/drivers/acpi/acpi_adxl.c
> @@ -0,0 +1,156 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Address translation interface via ACPI DSM.
> + * Copyright (C) 2018 Intel Corporation
> + */
> +
> +#ifdef CONFIG_ACPI_ADXL
> +#include <linux/acpi.h>
> +#include <linux/adxl.h>
> +
> +#define ADXL_REV				0x1
> +#define ADXL_IDX_GET_ADDR_PARAMS		0x1
> +#define ADXL_IDX_FORWARD_TRANSLATE	0x2
> +#define ACPI_ADXL_PATH			"\\_SB.ADXL"
> +
> +#undef pr_fmt
> +#define pr_fmt(fmt) "ADXL: " fmt
> +
> +static acpi_handle handle;
> +static union acpi_object *params;
> +static const guid_t adxl_guid =
> +	GUID_INIT(0xAA3C050A, 0x7EA4, 0x4C1F,
> +		  0xAF, 0xDA, 0x12, 0x67, 0xDF, 0xD3, 0xD4, 0x8D);
> +
> +int adxl_count;
> +EXPORT_SYMBOL_GPL(adxl_count);

That's the length of the address components adxl_component_names array?

> +char **adxl_component_names;
> +EXPORT_SYMBOL_GPL(adxl_component_names);

I guess I'm still unclear on how this is going to be used...

/me goes and looks at the initial patch.

aha, the DSM replies with a bunch of components which map to the names
and they'll get filled up by BIOS and the driver simply dumps them.
Something along those lines at least.

So you don't need count if you NULL-terminate the names array, right?

So you can simply do

	kcalloc(cnt + 1, ...

and the last element will be NULL.

Somehow exporting that naked count looks strange to me. If at all, it
should be read-only, I guess __ro_after_init or so.

Other than that minor stuff, it looks ok to me.

Thx.