All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: "Luck, Tony" <tony.luck@intel.com>
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 17:14:55 +0200	[thread overview]
Message-ID: <20181009151455.GD16287@zn.tnic> (raw)

On Mon, Oct 08, 2018 at 09:57:06AM -0700, Luck, Tony wrote:
> This shouldn't conflict with other BIOS "value add" code for firmware
> first mode, etc.

"value add", yeah. So something has been added - dunno if it is of value.

> +/**
> + * adxl_get_component_names - get list of memory component names
> + * Returns NULL terminated list of string names
> + *
> + * Give the caller a pointer to the list of memory component names
> + * e.g. { "SystemAddress", "ProcessorSocketId", "ChannelId", ... NULL }
> + * Caller should count how many strings in order to allocate a buffer
> + * for the return from adxl_decode()

Nit: please end all your comments' sentences with a full stop.

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.

Also, you could point to how skx_edac is using this interface so that
people can get a good example.

> + */
> +char **adxl_get_component_names(void)
> +{
> +	return adxl_component_names;

Should this array be immutable? I.e., const char * const. So that people
don't accidentally overwrite it or poke funny chars in it.

> +}
> +EXPORT_SYMBOL_GPL(adxl_get_component_names);
> +
> +/**
> + * adxl_decode - ask BIOS to decode a system address to memory address
> + * @addr: the address to decode
> + * @component_values: pointer to array of values for each component
> + * Returns 0 on success, negative error code otherwise
> + *
> + * The index of each value returned in the array matches the index of
> + * each component name returned by adxl_get_component_names().
> + * Components that are not defined for this address translation (e.g.
> + * mirror channel number for a non-mirrored address) are set to ~0ull
> + */
> +int adxl_decode(u64 addr, u64 component_values[])
> +{
> +	union acpi_object argv4[2], *results, *r;
> +	int i, cnt;
> +
> +	if (!adxl_component_names)
> +		return -EOPNOTSUPP;
> +
> +	argv4[0].type = ACPI_TYPE_PACKAGE;
> +	argv4[0].package.count = 1;
> +	argv4[0].package.elements = &argv4[1];
> +	argv4[1].integer.type = ACPI_TYPE_INTEGER;
> +	argv4[1].integer.value = addr;
> +
> +	results = adxl_dsm(ADXL_IDX_FORWARD_TRANSLATE, argv4);
> +

Superfluous newline.

> +	if (!results)
> +		return -EINVAL;
> +
> +	r = results->package.elements + 1;
> +	cnt = r->package.count;
> +	r = r->package.elements;
> +
> +	for (i = 0; i < cnt; i++)
> +		component_values[i] = r[i].integer.value;
> +
> +	ACPI_FREE(results);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(adxl_decode);
> +
> +static bool adxl_detect(void)
> +{
> +	char *path = ACPI_ADXL_PATH;
> +	union acpi_object *p;
> +	acpi_status status;
> +	int i, cnt;
> +
> +	status = acpi_get_handle(NULL, path, &handle);
> +	if (ACPI_FAILURE(status)) {
> +		pr_debug("No ACPI handle for path %s\n", path);

Shouldn't all those be pr_info?

We had the same problem with einj.ko and not knowing why it wouldn't load.

> +		return false;
> +	}
> +
> +	if (!acpi_has_method(handle, "_DSM")) {
> +		pr_debug("No DSM method\n");
> +		return false;
> +	}
> +
> +	if (!acpi_check_dsm(handle, &adxl_guid, ADXL_REVISION,
> +			    ADXL_IDX_GET_ADDR_PARAMS |
> +			    ADXL_IDX_FORWARD_TRANSLATE)) {
> +		pr_debug("No ADXL DSM methods\n");
> +		return false;
> +	}
> +
> +	params = adxl_dsm(ADXL_IDX_GET_ADDR_PARAMS, NULL);
> +	if (!params) {
> +		pr_debug("Failed to get params\n");
> +		return false;
> +	}
> +
> +	p = params->package.elements + 1;
> +	cnt = p->package.count;

I guess you need to sanity-check that count - we don't trust BIOS and
you have a firmware-controlled allocation size.

> +	p = p->package.elements;
> +
> +	adxl_component_names = kcalloc(cnt + 1, sizeof(char *), GFP_KERNEL);
> +	if (!adxl_component_names) {
> +		ACPI_FREE(params);
> +		return false;
> +	}
> +
> +	for (i = 0; i < cnt; i++)
> +		adxl_component_names[i] = p[i].string.pointer;
> +
> +	return true;
> +}

             reply	other threads:[~2018-10-09 15:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-09 15:14 Borislav Petkov [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-10-09 18:33 [4/5] EDAC, dsm_edac: Wrap ACPI DSM methods for address translation Luck, Tony
2018-10-09 18:29 Luck, Tony
2018-10-09 16:17 Borislav Petkov
2018-10-09 15:29 Rafael J. Wysocki
2018-10-09 15:25 Rafael J. Wysocki
2018-10-09 15:22 Luck, Tony
2018-10-09 11:43 Qiuxu Zhuo
2018-10-09 10:28 Rafael J. Wysocki
2018-10-08 16:57 Luck, Tony
2018-10-06 20:44 Borislav Petkov
2018-10-05 22:25 Luck, Tony
2018-10-04  9:31 Borislav Petkov
2018-10-03 17:58 Luck, Tony
2018-09-26 18:22 Luck, Tony
2018-09-26 17:33 Borislav Petkov
2018-09-24 20:16 Luck, Tony

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181009151455.GD16287@zn.tnic \
    --to=bp@alien8.de \
    --cc=aris@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=mchehab@s-opensource.com \
    --cc=qiuxu.zhuo@intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.