Re: [PATCH v17 05/18] cxl: Add Get Supported Features command for kernel usage

Dan Williams
2024-12-06T21:41:11Z

shiju.jose@ wrote:
> From: Dave Jiang <dave.jiang@intel.com>
>
> CXL spec r3.1 8.2.9.6.1 Get Supported Features (Opcode 0500h)
> The command retrieve the list of supported device-specific features
> (identified by UUID) and general information about each Feature.
>
> The driver will retrieve the feature entries in order to make checks and
> provide information for the Get Feature and Set Feature command. One of
> the main piece of information retrieved are the effects a Set Feature
> command would have for a particular feature.
>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
> Co-developed-by: Shiju Jose <shiju.jose@huawei.com>
> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
> ---
> drivers/cxl/core/mbox.c | 179 +++++++++++++++++++++++++++++++++++
> drivers/cxl/cxlmem.h | 44 +++++++++
> drivers/cxl/pci.c | 4 +
> include/cxl/mailbox.h | 4 +
> include/uapi/linux/cxl_mem.h | 1 +
> 5 files changed, 232 insertions(+)

Hi Shiju,

So I commented yesterday on this patch that is also duplicated in Dave's
series have a merge order ordering plan to propose.

> diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
> index 880ac1dba3cc..c5d4c7df2f99 100644
> --- a/drivers/cxl/core/mbox.c
> +++ b/drivers/cxl/core/mbox.c
> @@ -67,6 +67,7 @@ static struct cxl_mem_command cxl_mem_commands[CXL_MEM_COMMAND_ID_MAX] = {
> CXL_CMD(SET_SHUTDOWN_STATE, 0x1, 0, 0),
> CXL_CMD(GET_SCAN_MEDIA_CAPS, 0x10, 0x4, 0),
> CXL_CMD(GET_TIMESTAMP, 0, 0x8, 0),
> + CXL_CMD(GET_SUPPORTED_FEATURES, 0x8, CXL_VARIABLE_PAYLOAD, 0),

As I mention on the CXL FWCTL alias of this path, for kernel-internal
only usage by definition that means a CXL command id does not need to be
defined.

Setting that aside, the place where CXL EDAC and CXL FWCTL series can
unify is on the definition of the cxl_{get,set}_features() helpers
proposed in this series for kernel-internal submission of CXL FEATURES
commands. I think Dave's series should ingest cxl_{get,set}_features(),
go in first since it does not have cross-subsystem entanglements, and
then you can build reuse that infrastructure to finalize the CXL scrub
implementation.

The missing piece in my mind to make cxl_{get,set}_features() usable
with the CXL FWCTL path is likely to make it be able to support copying
in / out of __user buffers. To me that looks like updating
cxl_internal_send_cmd() to use copy_{to,from}_sockptr() internally so
that it is independent of the kernel vs user buffer concern from CXL
EDAC vs CXL FWCTL callers.