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

From: "Luck, Tony" <tony.luck@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
	Aristeu Rozanski <aris@redhat.com>,
	Mauro Carvalho Chehab <mchehab@s-opensource.com>,
	linux-edac@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: [4/5] EDAC, dsm_edac: Wrap ACPI DSM methods for address translation
Date: Tue, 9 Oct 2018 11:29:32 -0700	[thread overview]
Message-ID: <20181009182932.GA20408@agluck-desk> (raw)

On Tue, Oct 09, 2018 at 05:14:55PM +0200, Borislav Petkov wrote:
> Not so nitty: there's no guarantee that the order and string formatting of
> all those is stable, right? I think you should state that in the driver
> so that people don't get crazy ideas of relying on any of this. It is a
> best effort and no more, I'd assume.

When we designed the interface for this call we didn't ever
want to update it again. So we went overboard with this idea
that a memory address can be expressed as a series of:

	{ component_name, value }

tuples.  So in the future if someone adds a whole bunch of new
layers between existing "normal" systems, the inetrface will
just work (TM).

Then when Qiuxu updated the EDAC driver, we found that we do
care about three components. So if the BIOS messes with the
names, or order, we'd be in a bind.

So we added module parameters for each of the three names.
If the driver doesn't find the hard-coded names, it prints
out all the ones the ADXL DSM gave us, and the user can
make the best guess on which match what the driver needs.

About to post new patch series.  See part 3.

-Tony