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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux