linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Dave Jiang <dave.jiang@intel.com>
Cc: <linux-cxl@vger.kernel.org>, <linux-pci@vger.kernel.org>,
	<linux-acpi@vger.kernel.org>, <dan.j.williams@intel.com>,
	<ira.weiny@intel.com>, <vishal.l.verma@intel.com>,
	<alison.schofield@intel.com>, <rafael@kernel.org>,
	<bhelgaas@google.com>, <robert.moore@intel.com>
Subject: Re: [PATCH 04/18] cxl: Add common helpers for cdat parsing
Date: Thu, 9 Feb 2023 11:58:03 +0000	[thread overview]
Message-ID: <20230209115803.00002778@Huawei.com> (raw)
In-Reply-To: <167571659666.587790.1381783105886436293.stgit@djiang5-mobl3.local>

On Mon, 06 Feb 2023 13:49:58 -0700
Dave Jiang <dave.jiang@intel.com> wrote:

> Add helper functions to parse the CDAT table and provide a callback to
> parse the sub-table. Helpers are provided for DSMAS and DSLBIS sub-table
> parsing. The code is patterned after the ACPI table parsing helpers.
> 
> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
> ---
>  drivers/cxl/core/Makefile |    1 
>  drivers/cxl/core/cdat.c   |   98 +++++++++++++++++++++++++++++++++++++++++++++
>  drivers/cxl/core/cdat.h   |   15 +++++++
>  drivers/cxl/cxl.h         |    9 ++++
>  4 files changed, 123 insertions(+)
>  create mode 100644 drivers/cxl/core/cdat.c
>  create mode 100644 drivers/cxl/core/cdat.h
> 
> diff --git a/drivers/cxl/core/Makefile b/drivers/cxl/core/Makefile
> index 79c7257f4107..438ce27faf77 100644
> --- a/drivers/cxl/core/Makefile
> +++ b/drivers/cxl/core/Makefile
> @@ -10,4 +10,5 @@ cxl_core-y += memdev.o
>  cxl_core-y += mbox.o
>  cxl_core-y += pci.o
>  cxl_core-y += hdm.o
> +cxl_core-y += cdat.o
>  cxl_core-$(CONFIG_CXL_REGION) += region.o
> diff --git a/drivers/cxl/core/cdat.c b/drivers/cxl/core/cdat.c
> new file mode 100644
> index 000000000000..be09c8a690f5
> --- /dev/null
> +++ b/drivers/cxl/core/cdat.c
> @@ -0,0 +1,98 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright(c) 2023 Intel Corporation. All rights reserved. */
> +#include "cxl.h"
> +#include "cdat.h"
> +
> +static u8 cdat_get_subtable_entry_type(struct cdat_subtable_entry *entry)
> +{
> +	return entry->hdr->type;
> +}

Are these all worthwhile given the resulting function name is longer
than accessing it directly.  If aim is to move the details of the
struct cdat_subtable_entry away from being exposed at caller, then
fair enough, but if that is the plan I'd expect to see something about
that in the patch description.

Feels like some premature abstraction, but I don't feel particularly
strongly about this.


> +
> +static u16 cdat_get_subtable_entry_length(struct cdat_subtable_entry *entry)
> +{
> +	return entry->hdr->length;
> +}
> +
> +static bool has_handler(struct cdat_subtable_proc *proc)
> +{
> +	return proc->handler;
> +}
> +
> +static int call_handler(struct cdat_subtable_proc *proc,
> +			struct cdat_subtable_entry *ent)
> +{
> +	if (proc->handler)

Use your wrapper...

> +		return proc->handler(ent->hdr, proc->arg);
> +	return -EINVAL;
> +}
> +
> +static int cdat_table_parse_entries(enum acpi_cdat_type type,
> +				    struct acpi_table_cdat *table_header,
> +				    struct cdat_subtable_proc *proc,
> +				    unsigned int max_entries)

Documentation needed.  max_entries wasn't what I was expecting.
I would have expected it to be a cap on number of entries of
matching type, whereas it seems to be number of entries of any type.

Also, max_entries == 0 non obvious parameter value.


> +{
> +	struct cdat_subtable_entry entry;
> +	unsigned long table_end, entry_len;
> +	int count = 0;
> +	int rc;
> +
> +	if (!has_handler(proc))
> +		return -EINVAL;
> +
> +	table_end = (unsigned long)table_header + table_header->length;
> +
> +	if (type >= ACPI_CDAT_TYPE_RESERVED)
> +		return -EINVAL;
> +
> +	entry.type = type;
> +	entry.hdr = (struct acpi_cdat_header *)((unsigned long)table_header +
> +					       sizeof(*table_header));

Common idiom for this is.

	entry.hdr = (struct acpi_cdat_header *)(table_header + 1);

> +
> +	while ((unsigned long)entry.hdr < table_end) {
> +		entry_len = cdat_get_subtable_entry_length(&entry);
> +
> +		if ((unsigned long)entry.hdr + entry_len > table_end)
> +			return -EINVAL;
> +
> +		if (max_entries && count >= max_entries)
> +			break;
> +
> +		if (entry_len == 0)
> +			return -EINVAL;
> +
> +		if (cdat_get_subtable_entry_type(&entry) == type) {

This is a little odd as we set entry.type above == type, but
the match here is on the value in the one in entry.hdr.

That's not particularly intuitive. Not sure on what a good solution
would be though.  Maybe just

		if (cdat_is_subtable_match(&entry))

> +			rc = call_handler(proc, &entry);
> +			if (rc)
> +				return rc;
> +		}

As above.  Maybe intent, but my initial assumption would have had
count not incremented unless there was a match. (so put it in this if block
not below)

> +
> +		entry.hdr = (struct acpi_cdat_header *)((unsigned long)entry.hdr + entry_len);
> +		count++;
> +	}
> +
> +	return count;
> +}
> +
> +int cdat_table_parse_dsmas(void *table, cdat_tbl_entry_handler handler, void *arg)
> +{
> +	struct acpi_table_cdat *header = (struct acpi_table_cdat *)table;

Now struct acpi_table_cdata exists, maybe just move to using
that type for all references.  Will make a mess of the range checking
efforts the hardening folk are working on as we will index off end of
it and it doesn't have a variable length array trailing element.

Random musing follows...
We could add a variable length element to that struct
definition and the magic to associate that with the length parameter
and get range protection if relevant hardening is turned on.

Structure definition comes (I think) from scripts in acpica so
would need to push such changes into acpica and I'm not sure
they will be keen even though it would be good for the kernel
to have the protections.

https://people.kernel.org/kees/bounded-flexible-arrays-in-c
for Kees Cook's blog on this stuff.  The last bit needs
the 'comming soon' part.

> +	struct cdat_subtable_proc proc = {
> +		.handler	= handler,
> +		.arg		= arg,
> +	};
> +
> +	return cdat_table_parse_entries(ACPI_CDAT_TYPE_DSMAS, header, &proc, 0);
> +}
> +EXPORT_SYMBOL_NS_GPL(cdat_table_parse_dsmas, CXL);
> +
> +int cdat_table_parse_dslbis(void *table, cdat_tbl_entry_handler handler, void *arg)
> +{
> +	struct acpi_table_cdat *header = (struct acpi_table_cdat *)table;
> +	struct cdat_subtable_proc proc = {
> +		.handler	= handler,
> +		.arg		= arg,
> +	};
> +
> +	return cdat_table_parse_entries(ACPI_CDAT_TYPE_DSLBIS, header, &proc, 0);
> +}
> +EXPORT_SYMBOL_NS_GPL(cdat_table_parse_dslbis, CXL);
> diff --git a/drivers/cxl/core/cdat.h b/drivers/cxl/core/cdat.h
> new file mode 100644
> index 000000000000..f690325e82a6
> --- /dev/null
> +++ b/drivers/cxl/core/cdat.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/* Copyright(c) 2023 Intel Corporation. */
> +#ifndef __CXL_CDAT_H__
> +#define __CXL_CDAT_H__
> +
> +struct cdat_subtable_proc {
> +	cdat_tbl_entry_handler handler;
> +	void *arg;
> +};
> +
> +struct cdat_subtable_entry {
> +	struct acpi_cdat_header *hdr;
> +	enum acpi_cdat_type type;
> +};
> +#endif
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index f558bbfc0332..839a121c1997 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -9,6 +9,7 @@
>  #include <linux/bitops.h>
>  #include <linux/log2.h>
>  #include <linux/io.h>
> +#include <linux/acpi.h>
>  
>  /**
>   * DOC: cxl objects
> @@ -697,6 +698,14 @@ static inline struct cxl_pmem_region *to_cxl_pmem_region(struct device *dev)
>  }
>  #endif
>  
> +typedef int (*cdat_tbl_entry_handler)(struct acpi_cdat_header *header, void *arg);
> +
> +u8 cdat_table_checksum(u8 *buffer, u32 length);
> +int cdat_table_parse_dsmas(void *table, cdat_tbl_entry_handler handler,
> +			   void *arg);
> +int cdat_table_parse_dslbis(void *table, cdat_tbl_entry_handler handler,
> +			    void *arg);
> +
>  /*
>   * Unit test builds overrides this to __weak, find the 'strong' version
>   * of these symbols in tools/testing/cxl/.
> 
> 


  reply	other threads:[~2023-02-09 12:07 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-06 20:49 [PATCH 00/18] cxl: Add support for QTG ID retrieval for CXL subsystem Dave Jiang
2023-02-06 20:49 ` [PATCH 01/18] cxl: Export QTG ids from CFMWS to sysfs Dave Jiang
2023-02-09 11:15   ` Jonathan Cameron
2023-02-09 17:28     ` Dave Jiang
2023-02-06 20:49 ` [PATCH 02/18] ACPICA: Export acpi_ut_verify_cdat_checksum() Dave Jiang
2023-02-07 14:19   ` Rafael J. Wysocki
2023-02-07 15:47     ` Dave Jiang
2023-02-09 11:30       ` Jonathan Cameron
2023-02-06 20:49 ` [PATCH 03/18] cxl: Add checksum verification to CDAT from CXL Dave Jiang
2023-02-09 11:34   ` Jonathan Cameron
2023-02-09 17:31     ` Dave Jiang
2023-02-06 20:49 ` [PATCH 04/18] cxl: Add common helpers for cdat parsing Dave Jiang
2023-02-09 11:58   ` Jonathan Cameron [this message]
2023-02-09 22:57     ` Dave Jiang
2023-02-11 10:18       ` Lukas Wunner
2023-02-14 13:17         ` Jonathan Cameron
2023-02-14 20:36         ` Dave Jiang
2023-02-06 20:50 ` [PATCH 05/18] ACPICA: Fix 'struct acpi_cdat_dsmas' spelling mistake Dave Jiang
2023-02-06 22:00   ` Lukas Wunner
2023-02-06 20:50 ` [PATCH 06/18] cxl: Add callback to parse the DSMAS subtables from CDAT Dave Jiang
2023-02-09 13:29   ` Jonathan Cameron
2023-02-13 22:55     ` Dave Jiang
2023-02-06 20:50 ` [PATCH 07/18] cxl: Add callback to parse the DSLBIS subtable " Dave Jiang
2023-02-09 13:50   ` Jonathan Cameron
2023-02-14  0:24     ` Dave Jiang
2023-02-06 20:50 ` [PATCH 08/18] cxl: Add support for _DSM Function for retrieving QTG ID Dave Jiang
2023-02-09 14:02   ` Jonathan Cameron
2023-02-14 21:07     ` Dave Jiang
2023-02-06 20:50 ` [PATCH 09/18] cxl: Add helper function to retrieve ACPI handle of CXL root device Dave Jiang
2023-02-09 14:10   ` Jonathan Cameron
2023-02-14 21:29     ` Dave Jiang
2023-02-06 20:50 ` [PATCH 10/18] PCI: Export pcie_get_speed() using the code from sysfs PCI link speed show function Dave Jiang
2023-02-06 22:27   ` Lukas Wunner
2023-02-07 20:29     ` Dave Jiang
2023-02-06 20:51 ` [PATCH 11/18] PCI: Export pcie_get_width() using the code from sysfs PCI link width " Dave Jiang
2023-02-06 22:43   ` Bjorn Helgaas
2023-02-07 20:35     ` Dave Jiang
2023-02-06 20:51 ` [PATCH 12/18] cxl: Add helpers to calculate pci latency for the CXL device Dave Jiang
2023-02-06 22:39   ` Bjorn Helgaas
2023-02-07 20:51     ` Dave Jiang
2023-02-08 22:15       ` Bjorn Helgaas
2023-02-08 23:56         ` Dave Jiang
2023-02-09 15:10           ` Jonathan Cameron
2023-02-14 22:22             ` Dave Jiang
2023-02-15 12:13               ` Jonathan Cameron
2023-02-22 17:54                 ` Dave Jiang
2023-02-09 15:16   ` Jonathan Cameron
2023-02-06 20:51 ` [PATCH 13/18] cxl: Add latency and bandwidth calculations for the CXL path Dave Jiang
2023-02-09 15:24   ` Jonathan Cameron
2023-02-14 23:03     ` Dave Jiang
2023-02-15 13:17       ` Jonathan Cameron
2023-02-15 16:38         ` Dave Jiang
2023-02-06 20:51 ` [PATCH 14/18] cxl: Wait Memory_Info_Valid before access memory related info Dave Jiang
2023-02-09 15:29   ` Jonathan Cameron
2023-02-06 20:51 ` [PATCH 15/18] cxl: Move identify and partition query from pci probe to port probe Dave Jiang
2023-02-09 15:29   ` Jonathan Cameron
2023-02-06 20:51 ` [PATCH 16/18] cxl: Move reading of CDAT data from device to after media is ready Dave Jiang
2023-02-06 22:17   ` Lukas Wunner
2023-02-07 20:55     ` Dave Jiang
2023-02-09 15:31   ` Jonathan Cameron
2023-02-06 20:51 ` [PATCH 17/18] cxl: Attach QTG IDs to the DPA ranges for the device Dave Jiang
2023-02-09 15:34   ` Jonathan Cameron
2023-02-06 20:52 ` [PATCH 18/18] cxl: Export sysfs attributes for device QTG IDs Dave Jiang
2023-02-09 15:41   ` Jonathan Cameron
2023-03-23 23:20     ` Dan Williams

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=20230209115803.00002778@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robert.moore@intel.com \
    --cc=vishal.l.verma@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).