linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: <shiju.jose@huawei.com>
Cc: <linux-cxl@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
	<linux-mm@kvack.org>, <dan.j.williams@intel.com>,
	<dave@stgolabs.net>, <dave.jiang@intel.com>,
	<alison.schofield@intel.com>, <vishal.l.verma@intel.com>,
	<ira.weiny@intel.com>, <linux-edac@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <david@redhat.com>,
	<Vilas.Sridharan@amd.com>, <leo.duran@amd.com>,
	<Yazen.Ghannam@amd.com>, <rientjes@google.com>,
	<jiaqiyan@google.com>, <tony.luck@intel.com>, <Jon.Grimm@amd.com>,
	<dave.hansen@linux.intel.com>, <rafael@kernel.org>,
	<lenb@kernel.org>, <naoya.horiguchi@nec.com>,
	<james.morse@arm.com>, <jthoughton@google.com>,
	<somasundaram.a@hpe.com>, <erdemaktas@google.com>,
	<pgonda@google.com>, <duenwen@google.com>,
	<mike.malvestuto@intel.com>, <gthelen@google.com>,
	<wschwartz@amperecomputing.com>, <dferguson@amperecomputing.com>,
	<tanxiaofei@huawei.com>, <prime.zeng@hisilicon.com>,
	<kangkang.shen@futurewei.com>, <wanghuiqiang@huawei.com>,
	<linuxarm@huawei.com>
Subject: Re: [RFC PATCH v6 02/12] cxl/mbox: Add GET_FEATURE mailbox command
Date: Tue, 20 Feb 2024 11:14:23 +0000	[thread overview]
Message-ID: <20240220111423.00003eae@Huawei.com> (raw)
In-Reply-To: <20240215111455.1462-3-shiju.jose@huawei.com>

On Thu, 15 Feb 2024 19:14:44 +0800
<shiju.jose@huawei.com> wrote:

> From: Shiju Jose <shiju.jose@huawei.com>
> 
> Add support for GET_FEATURE mailbox command.
> 
> CXL spec 3.1 section 8.2.9.6 describes optional device specific features.
> The settings of a feature can be retrieved using Get Feature command.
Hi Shiju

I think this needs to be more complex so that this utility function gets
the whole feature, not just a section of it (subject to big enough buffer
being available etc).  We don't want the higher level code to have to
deal with the complexity of small mailboxes.

A few other things inline.

Jonathan

> 
> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
> ---
>  drivers/cxl/core/mbox.c | 22 ++++++++++++++++++++++
>  drivers/cxl/cxlmem.h    | 23 +++++++++++++++++++++++
>  2 files changed, 45 insertions(+)
> 
> diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
> index 191f51f3df0e..f43189b6859a 100644
> --- a/drivers/cxl/core/mbox.c
> +++ b/drivers/cxl/core/mbox.c
> @@ -1313,6 +1313,28 @@ int cxl_get_supported_features(struct cxl_memdev_state *mds,
>  }
>  EXPORT_SYMBOL_NS_GPL(cxl_get_supported_features, CXL);
>  
> +int cxl_get_feature(struct cxl_memdev_state *mds,
> +		    struct cxl_mbox_get_feat_in *pi, void *feat_out)

Comments below on this signature.  Key is I'd expect this function to deal
with potential need for multiple requests (small mailbox size compared to
the size of the output data being read).

To test that we'd probably have to tweak the qemu code to use a smaller mailbox.
Or fake that in here so that we do multiple smaller reads.

> +{
> +	struct cxl_mbox_cmd mbox_cmd;
> +	int rc;
> +
> +	mbox_cmd = (struct cxl_mbox_cmd) {
> +		.opcode = CXL_MBOX_OP_GET_FEATURE,
> +		.size_in = sizeof(*pi),
> +		.payload_in = pi,
> +		.size_out = le16_to_cpu(pi->count),
> +		.payload_out = feat_out,
> +		.min_out = le16_to_cpu(pi->count),

Are there feature with variable responses sizes?  I think there will be.
size_out should be the size of the buffer, but min_out should be
the size of the particular feature data header - note these will change
as we iterate over multiple messages.


> +	};
> +	rc = cxl_internal_send_cmd(mds, &mbox_cmd);
> +	if (rc < 0)
> +		return rc;
> +
> +	return 0;
I think this should return the size to the caller, rather than 0 on success.

> +}
> +EXPORT_SYMBOL_NS_GPL(cxl_get_feature, CXL);
> +
>  int cxl_mem_get_poison(struct cxl_memdev *cxlmd, u64 offset, u64 len,
>  		       struct cxl_region *cxlr)
>  {
> diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
> index 23e4d98b9bae..eaecc3234cfd 100644
> --- a/drivers/cxl/cxlmem.h
> +++ b/drivers/cxl/cxlmem.h
> @@ -530,6 +530,7 @@ enum cxl_opcode {
>  	CXL_MBOX_OP_GET_SUPPORTED_LOGS	= 0x0400,
>  	CXL_MBOX_OP_GET_LOG		= 0x0401,
>  	CXL_MBOX_OP_GET_SUPPORTED_FEATURES	= 0x0500,
> +	CXL_MBOX_OP_GET_FEATURE		= 0x0501,
>  	CXL_MBOX_OP_IDENTIFY		= 0x4000,
>  	CXL_MBOX_OP_GET_PARTITION_INFO	= 0x4100,
>  	CXL_MBOX_OP_SET_PARTITION_INFO	= 0x4101,
> @@ -757,6 +758,26 @@ struct cxl_mbox_get_supp_feats_out {
>  	struct cxl_mbox_supp_feat_entry feat_entries[];
>  } __packed;
>  
> +/* Get Feature CXL 3.1 Spec 8.2.9.6.2 */
> +/*
> + * Get Feature input payload
> + * CXL rev 3.1 section 8.2.9.6.2 Table 8-99
> + */
> +/* Get Feature : Payload in selection */

Naming of enum is good enough that I don't think we need
this particular comment.

> +enum cxl_get_feat_selection {
> +	CXL_GET_FEAT_SEL_CURRENT_VALUE,
> +	CXL_GET_FEAT_SEL_DEFAULT_VALUE,
> +	CXL_GET_FEAT_SEL_SAVED_VALUE,
> +	CXL_GET_FEAT_SEL_MAX
> +};
> +
> +struct cxl_mbox_get_feat_in {
> +	uuid_t uuid;
> +	__le16 offset;
> +	__le16 count;
> +	u8 selection;
> +}  __packed;
> +
>  /* Get Poison List  CXL 3.0 Spec 8.2.9.8.4.1 */
>  struct cxl_mbox_poison_in {
>  	__le64 offset;
> @@ -891,6 +912,8 @@ int cxl_set_timestamp(struct cxl_memdev_state *mds);
>  int cxl_get_supported_features(struct cxl_memdev_state *mds,
>  			       struct cxl_mbox_get_supp_feats_in *pi,
>  			       void *feats_out);
> +int cxl_get_feature(struct cxl_memdev_state *mds,
> +		    struct cxl_mbox_get_feat_in *pi, void *feat_out);

For this I'd expect us to wrap up the need for multi messages inside this.
So this would then just take the feature index, a size for the output buffer
overall size, plus min acceptable response size and a selection enum value.

int cxl_get_feature(struct cxl_memdev_state *mds,
		    uuid_t feat,
		    void *feat_out, size_t feat_out_min_size,
		    size_t feat_out_size);

>  int cxl_poison_state_init(struct cxl_memdev_state *mds);
>  int cxl_mem_get_poison(struct cxl_memdev *cxlmd, u64 offset, u64 len,
>  		       struct cxl_region *cxlr);


  reply	other threads:[~2024-02-20 11:14 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 11:14 [RFC PATCH v6 00/12] cxl: Add support for CXL feature commands, CXL device patrol scrub control and DDR5 ECS control features shiju.jose
2024-02-15 11:14 ` [RFC PATCH v6 01/12] cxl/mbox: Add GET_SUPPORTED_FEATURES mailbox command shiju.jose
2024-02-20 11:02   ` Jonathan Cameron
2024-03-05 23:57   ` fan
2024-02-15 11:14 ` [RFC PATCH v6 02/12] cxl/mbox: Add GET_FEATURE " shiju.jose
2024-02-20 11:14   ` Jonathan Cameron [this message]
2024-02-23 12:23     ` Shiju Jose
2024-02-15 11:14 ` [RFC PATCH v6 03/12] cxl/mbox: Add SET_FEATURE " shiju.jose
2024-02-20 11:27   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 04/12] cxl/memscrub: Add CXL device patrol scrub control feature shiju.jose
2024-02-20 11:59   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 05/12] cxl/memscrub: Add CXL device ECS " shiju.jose
2024-02-20 12:17   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 06/12] memory: scrub: Add scrub subsystem driver supports configuring memory scrubs in the system shiju.jose
2024-02-20 12:39   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 07/12] cxl/memscrub: Register CXL device patrol scrub with scrub configure driver shiju.jose
2024-02-20 12:43   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 08/12] cxl/memscrub: Register CXL device ECS " shiju.jose
2024-02-20 13:39   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 09/12] ACPI:RASF: Add common library for RASF and RAS2 PCC interfaces shiju.jose
2024-02-20 13:53   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 10/12] ACPICA: ACPI 6.5: Add support for RAS2 table shiju.jose
2024-02-20 13:58   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 11/12] ACPI:RAS2: Add driver for ACPI RAS2 feature table (RAS2) shiju.jose
2024-02-15 11:14 ` [RFC PATCH v6 12/12] memory: RAS2: Add memory RAS2 driver shiju.jose
2024-02-20 16:12   ` Jonathan Cameron
2024-02-22  0:20 ` [RFC PATCH v6 00/12] cxl: Add support for CXL feature commands, CXL device patrol scrub control and DDR5 ECS control features Dan Williams
2024-02-23 12:16   ` Shiju Jose
2024-02-23 19:42     ` Dan Williams
2024-02-26 10:29       ` Jonathan Cameron
2024-02-29 19:51         ` Dan Williams
2024-03-01 14:41           ` Jonathan Cameron
2024-03-05  0:52             ` Jiaqi Yan
2024-02-29 20:41         ` Tony Luck
2024-03-01 13:19           ` Jonathan Cameron
2024-02-28 22:26       ` John Groves

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=20240220111423.00003eae@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=Jon.Grimm@amd.com \
    --cc=Vilas.Sridharan@amd.com \
    --cc=Yazen.Ghannam@amd.com \
    --cc=alison.schofield@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=david@redhat.com \
    --cc=dferguson@amperecomputing.com \
    --cc=duenwen@google.com \
    --cc=erdemaktas@google.com \
    --cc=gthelen@google.com \
    --cc=ira.weiny@intel.com \
    --cc=james.morse@arm.com \
    --cc=jiaqiyan@google.com \
    --cc=jthoughton@google.com \
    --cc=kangkang.shen@futurewei.com \
    --cc=lenb@kernel.org \
    --cc=leo.duran@amd.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxarm@huawei.com \
    --cc=mike.malvestuto@intel.com \
    --cc=naoya.horiguchi@nec.com \
    --cc=pgonda@google.com \
    --cc=prime.zeng@hisilicon.com \
    --cc=rafael@kernel.org \
    --cc=rientjes@google.com \
    --cc=shiju.jose@huawei.com \
    --cc=somasundaram.a@hpe.com \
    --cc=tanxiaofei@huawei.com \
    --cc=tony.luck@intel.com \
    --cc=vishal.l.verma@intel.com \
    --cc=wanghuiqiang@huawei.com \
    --cc=wschwartz@amperecomputing.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).