Hi Jonathan,
Thanks for the comments.
I will post the updated version incorporated with your suggestions in the series.
>-----Original Message-----
>From: Jonathan Cameron <jonathan.cameron@xxxxxxxxxx>
>Sent: 20 February 2024 11:14
>To: Shiju Jose <shiju.jose@xxxxxxxxxx>
>Cc: linux-cxl@xxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; linux-
>mm@xxxxxxxxx; dan.j.williams@xxxxxxxxx; dave@xxxxxxxxxxxx;
>dave.jiang@xxxxxxxxx; alison.schofield@xxxxxxxxx; vishal.l.verma@xxxxxxxxx;
>ira.weiny@xxxxxxxxx; linux-edac@xxxxxxxxxxxxxxx; linux-
>kernel@xxxxxxxxxxxxxxx; david@xxxxxxxxxx; Vilas.Sridharan@xxxxxxx;
>leo.duran@xxxxxxx; Yazen.Ghannam@xxxxxxx; rientjes@xxxxxxxxxx;
>jiaqiyan@xxxxxxxxxx; tony.luck@xxxxxxxxx; Jon.Grimm@xxxxxxx;
>dave.hansen@xxxxxxxxxxxxxxx; rafael@xxxxxxxxxx; lenb@xxxxxxxxxx;
>naoya.horiguchi@xxxxxxx; james.morse@xxxxxxx; jthoughton@xxxxxxxxxx;
>somasundaram.a@xxxxxxx; erdemaktas@xxxxxxxxxx; pgonda@xxxxxxxxxx;
>duenwen@xxxxxxxxxx; mike.malvestuto@xxxxxxxxx; gthelen@xxxxxxxxxx;
>wschwartz@xxxxxxxxxxxxxxxxxxx; dferguson@xxxxxxxxxxxxxxxxxxx;
>tanxiaofei <tanxiaofei@xxxxxxxxxx>; Zengtao (B) <prime.zeng@xxxxxxxxxxxxx>;
>kangkang.shen@xxxxxxxxxxxxx; wanghuiqiang <wanghuiqiang@xxxxxxxxxx>;
>Linuxarm <linuxarm@xxxxxxxxxx>
>Subject: Re: [RFC PATCH v6 02/12] cxl/mbox: Add GET_FEATURE mailbox
>command
>
>On Thu, 15 Feb 2024 19:14:44 +0800
><shiju.jose@xxxxxxxxxx> wrote:
>
>> From: Shiju Jose <shiju.jose@xxxxxxxxxx>
>>
>> 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.
Sure.
>
>A few other things inline.
>
>Jonathan
>
>>
>> Signed-off-by: Shiju Jose <shiju.jose@xxxxxxxxxx>
>> ---
>> 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.
Sure.
>
>> +{
>> + 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.
Sure.
>
>
>> + };
>> + 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.
I will change.
>
>> +}
>> +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.
I will change.
>
>> +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.
Sure.
>
>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);
Thanks,
Shiju
