Re: [PATCH v17 02/22] sfc: add cxl support

[<dan.j.williams@intel.com>]

alejandro.lucero-palau@ wrote:
> From: Alejandro Lucero <alucerop@amd.com>
> 
> Add CXL initialization based on new CXL API for accel drivers and make
> it dependent on kernel CXL configuration.

Looks ok, I do feel it is missing Documentation for how someone
determines that this support is even turned on. For example, if
git-bisect lands on this patch the end user will see SFC_CXL enabled in
their kernel and:

pci_dbg(pci_dev, "CXL_DVSEC_PCIE_DEVICE capability found\n");

...in dmesg, but the CXL functionality is disabled.

Not a showstopper, so:

Reviewed-by: Dan Williams <dan.j.williams@intel.com>

...but when you respin patch1 do consider adding a blurb somewhere about
how to detect that CXL is in effect so there is a chance for end users
to help triage CXL operation problems.

[..]
> diff --git a/drivers/net/ethernet/sfc/efx_cxl.c b/drivers/net/ethernet/sfc/efx_cxl.c
> new file mode 100644
> index 000000000000..f1db7284dee8
> --- /dev/null
> +++ b/drivers/net/ethernet/sfc/efx_cxl.c
> @@ -0,0 +1,55 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/****************************************************************************
> + *
> + * Driver for AMD network controllers and boards
> + * Copyright (C) 2025, Advanced Micro Devices, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> + * by the Free Software Foundation, incorporated herein by reference.

Per, Documentation/process/license-rules.rst SPDX supersedes the need to
include this boilerplate paragraph, right?

> + */
> +
> +#include <cxl/pci.h>
> +#include <linux/pci.h>
> +
> +#include "net_driver.h"
> +#include "efx_cxl.h"
> +
> +#define EFX_CTPIO_BUFFER_SIZE	SZ_256M
> +
> +int efx_cxl_init(struct efx_probe_data *probe_data)
> +{
> +	struct efx_nic *efx = &probe_data->efx;
> +	struct pci_dev *pci_dev = efx->pci_dev;
> +	struct efx_cxl *cxl;
> +	u16 dvsec;
> +
> +	probe_data->cxl_pio_initialised = false;
> +
> +	dvsec = pci_find_dvsec_capability(pci_dev, PCI_VENDOR_ID_CXL,
> +					  CXL_DVSEC_PCIE_DEVICE);
> +	if (!dvsec)
> +		return 0;
> +
> +	pci_dbg(pci_dev, "CXL_DVSEC_PCIE_DEVICE capability found\n");
> +
> +	/* Create a cxl_dev_state embedded in the cxl struct using cxl core api
> +	 * specifying no mbox available.
> +	 */
> +	cxl = devm_cxl_dev_state_create(&pci_dev->dev, CXL_DEVTYPE_DEVMEM,
> +					pci_dev->dev.id, dvsec, struct efx_cxl,
> +					cxlds, false);
> +
> +	if (!cxl)
> +		return -ENOMEM;
> +
> +	probe_data->cxl = cxl;

Just note that this defeats the purpose of the
devm_cxl_dev_state_create() scheme which is to allow a container_of()
association of cxl_dev_state with something like a driver's @probe_data.
In this case @probe_data is allocated before @cxl and the devm
allocation of @cxl means that it is freed *after* @probe_data, i.e. not
strictly reverse allocation order.

It is fine as long as nothing in a devm release path tries to walk back
to @probe_data from @cxl, but just something to be aware of.