Linux CXL
 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>, <dan.j.williams@intel.com>,
	<ira.weiny@intel.com>, <vishal.l.verma@intel.com>,
	<alison.schofield@intel.com>, <dave@stgolabs.net>,
	<jgg@nvidia.com>, <shiju.jose@huawei.com>
Subject: Re: [PATCH v2 02/16] cxl: Enumerate feature commands
Date: Mon, 3 Feb 2025 12:06:07 +0000	[thread overview]
Message-ID: <20250203120607.0000606a@huawei.com> (raw)
In-Reply-To: <20250201004459.466499-3-dave.jiang@intel.com>

On Fri, 31 Jan 2025 17:41:55 -0700
Dave Jiang <dave.jiang@intel.com> wrote:

> Add feature commands enumeration code in order to detect and enumerate
> the 3 feature related commands "get supported features", "get feature",
> and "set feature". The enumeration will help determine whether the driver
> can issue any of the 3 commands to the device.
> 
> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
> ---
> v2:
> - Setup allocation of cxlfs and move enumeration of commands to
>   the setup function.
> - Introduce features_capability enum. (Dan)
> - Name the setup function devm_cxl_add_features(). (Dan)
> - Drop 'cxl_mem_command' support. (Dan)
> - Move feature support to mem probe. (Dan)
> - Remove comma at last entry of data structs. (Jonathan)
Got carried away on this one.   Only drop them for termination
entries.  So MAX or NULL or similar.

> diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
> index bdb8f060f2c1..25fb7bd770b3 100644
> --- a/drivers/cxl/core/mbox.c
> +++ b/drivers/cxl/core/mbox.c
> @@ -69,6 +69,29 @@ static struct cxl_mem_command cxl_mem_commands[CXL_MEM_COMMAND_ID_MAX] = {
>  	CXL_CMD(GET_TIMESTAMP, 0, 0x8, 0),
>  };
>  
> +static u16 cxl_feature_commands[] = {
> +	CXL_MBOX_OP_GET_SUPPORTED_FEATURES,
> +	CXL_MBOX_OP_GET_FEATURE,
> +	CXL_MBOX_OP_SET_FEATURE

This one does want a trailing comma. Might be more feature commands in future.

> +};

> diff --git a/drivers/cxl/features.c b/drivers/cxl/features.c
> new file mode 100644
> index 000000000000..13b0b29ee102
> --- /dev/null
> +++ b/drivers/cxl/features.c
> @@ -0,0 +1,55 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright(c) 2024-2025 Intel Corporation. All rights reserved. */
> +#include <linux/device.h>
> +#include <cxl/mailbox.h>
> +#include <cxl/features.h>
> +#include "cxl.h"
> +#include "cxlmem.h"
> +#include "features.h"
> +
> +static void enumerate_feature_cmds(struct cxl_memdev *cxlmd)
> +{
> +	struct cxl_dev_state *cxlds = cxlmd->cxlds;
> +	struct cxl_mailbox *cxl_mbox = &cxlds->cxl_mbox;
> +	struct cxl_features_state *cxlfs = cxlds->cxlmd->cxlfs;
Going in circles?
	cxlmd->cxlfs;


> +	int fid;
> +
> +	fid = cxl_get_feature_command_id(CXL_MBOX_OP_GET_SUPPORTED_FEATURES);
> +	if (!test_bit(fid, cxl_mbox->feature_cmds))
> +		return;
> +
> +	fid = cxl_get_feature_command_id(CXL_MBOX_OP_GET_FEATURE);
> +	if (!test_bit(fid, cxl_mbox->feature_cmds))
> +		return;
> +
> +	cxlfs->cap = CXL_FEATURES_RO;
> +
> +	fid = cxl_get_feature_command_id(CXL_MBOX_OP_SET_FEATURE);
> +	if (!test_bit(fid, cxl_mbox->feature_cmds))
> +		return;
> +
> +	cxlfs->cap = CXL_FEATURES_RW;
> +}
> +
> +/**
> + * devm_cxl_add_features() - Allocate and initialize features context
> + * @cxlmd: CXL memory device
> + *
> + * Return 0 on success or -errno on failure.
> + */
> +int devm_cxl_add_features(struct cxl_memdev *cxlmd)
> +{
> +	struct cxl_features_state *cxlfs;
> +	struct device *dev = &cxlmd->dev;
> +
> +	cxlfs = devm_kzalloc(dev, sizeof(*cxlfs), GFP_KERNEL);
> +	if (!cxlfs)
> +		return -ENOMEM;
> +
> +	cxlmd->cxlfs = cxlfs;

So I was curious about this one and why we leave the pointer
hanging in the remove path + whether the two way pointer nest
is needed.

That gets dealt with in patch 8.

I'd be tempted to drag the bones of dev_cxlfs_allocate() to this
patch so that you can do that cleanup now and avoid some of the churn
of the later patches.

As for the two way pointer nest. I'm not sure it is needed.
Seems like most if not all places we use cxlmd->cxlfs have
just gotten it in the caller from cxlfs->cxlmd.
e.g. cxl_cxlfs_free() in patch 8. For here we could
just pass it into enumerate_feature_cmds.

Maybe Shiju's set needs it. I haven't checked.




> +	cxlfs->cxlmd = cxlmd;
> +	enumerate_feature_cmds(cxlmd);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_NS_GPL(devm_cxl_add_features, "CXL");

> diff --git a/include/cxl/features.h b/include/cxl/features.h
> new file mode 100644
> index 000000000000..eadf0d56553f
> --- /dev/null
> +++ b/include/cxl/features.h
> @@ -0,0 +1,35 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/* Copyright(c) 2024-2025 Intel Corporation. */
> +#ifndef __CXL_FEATURES_H__
> +#define __CXL_FEATURES_H__
> +
> +struct cxl_mailbox;
> +
> +/* Index IDs for CXL mailbox Feature commands */
> +enum feature_cmds {
> +	CXL_FEATURE_ID_GET_SUPPORTED_FEATURES = 0,
> +	CXL_FEATURE_ID_GET_FEATURE,
> +	CXL_FEATURE_ID_SET_FEATURE,
> +	CXL_FEATURE_ID_MAX
> +};
> +
> +/* Feature commands capability supported by a device */
> +enum cxl_features_capability {
> +	CXL_FEATURES_NONE = 0,
> +	CXL_FEATURES_RO,
> +	CXL_FEATURES_RW

Trivial but this one should have a trailing comma.  Maybe
we'll have a write only one!  Anyhow, it's not a terminating
entry so we shouldn't assume nothing comes after it.

> +};
> +
> +/**
> + * struct cxl_features_state - The Features state for the device
> + * @cxlmd: Pointer to cxl mem device
> + * @cap: Feature commands capability
> + * @num_features: total Features supported by the device
> + */
> +struct cxl_features_state {
> +	struct cxl_memdev *cxlmd;
> +	enum cxl_features_capability cap;
> +	int num_features;
> +};
> +
> +#endif


  reply	other threads:[~2025-02-03 12:06 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-01  0:41 [PATCH v2 0/16] cxl: Add CXL feature commands support via fwctl Dave Jiang
2025-02-01  0:41 ` [PATCH v2 01/16] cxl: Refactor user ioctl command path from mds to mailbox Dave Jiang
2025-02-01  0:41 ` [PATCH v2 02/16] cxl: Enumerate feature commands Dave Jiang
2025-02-03 12:06   ` Jonathan Cameron [this message]
2025-02-03 23:23     ` Dave Jiang
2025-02-01  0:41 ` [PATCH v2 03/16] cxl: Add Get Supported Features command for kernel usage Dave Jiang
2025-02-03 12:19   ` Jonathan Cameron
2025-02-01  0:41 ` [PATCH v2 04/16] cxl/test: Add Get Supported Features mailbox command support Dave Jiang
2025-02-03 12:22   ` Jonathan Cameron
2025-02-01  0:41 ` [PATCH v2 05/16] cxl/mbox: Add GET_FEATURE mailbox command Dave Jiang
2025-02-01  0:41 ` [PATCH v2 06/16] cxl/mbox: Add SET_FEATURE " Dave Jiang
2025-02-03 12:27   ` Jonathan Cameron
2025-02-01  0:42 ` [PATCH v2 07/16] cxl: Setup exclusive CXL features that are reserved for the kernel Dave Jiang
2025-02-01  0:42 ` [PATCH v2 08/16] cxl: Add FWCTL support to the CXL memdev driver Dave Jiang
2025-02-01  1:04   ` Dave Jiang
2025-02-03 12:42   ` Jonathan Cameron
2025-02-03 14:25     ` Jason Gunthorpe
2025-02-03 16:22       ` Dave Jiang
2025-02-03 16:30         ` Jason Gunthorpe
2025-02-01  0:42 ` [PATCH v2 09/16] cxl: Add support for FWCTL get driver information callback Dave Jiang
2025-02-03 12:43   ` Jonathan Cameron
2025-02-01  0:42 ` [PATCH v2 10/16] cxl: Move cxl feature command structs to user header Dave Jiang
2025-02-01  0:42 ` [PATCH v2 11/16] cxl: Add support for fwctl RPC command to enable CXL feature commands Dave Jiang
2025-02-03 13:03   ` Jonathan Cameron
2025-02-01  0:42 ` [PATCH v2 12/16] cxl: Add support to handle user feature commands for get feature Dave Jiang
2025-02-01  0:42 ` [PATCH v2 13/16] cxl: Add support to handle user feature commands for set feature Dave Jiang
2025-02-01  0:42 ` [PATCH v2 14/16] cxl/test: Add Get Feature support to cxl_test Dave Jiang
2025-02-01  0:42 ` [PATCH v2 15/16] cxl/test: Add Set " Dave Jiang
2025-02-01  0:42 ` [PATCH v2 16/16] fwctl/cxl: Add documentation to FWCTL CXL Dave Jiang
2025-02-03 13:08   ` Jonathan Cameron

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=20250203120607.0000606a@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=ira.weiny@intel.com \
    --cc=jgg@nvidia.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=shiju.jose@huawei.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