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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5488b215-63aa-4188-a569-118d356a8c32@amd.com>
Date: Wed, 6 Aug 2025 09:37:51 +0100
From: Alejandro Lucero Palau <alucerop@....com>
To: dan.j.williams@...el.com, alejandro.lucero-palau@....com,
 linux-cxl@...r.kernel.org, netdev@...r.kernel.org, edward.cree@....com,
 davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
 edumazet@...gle.com, dave.jiang@...el.com
Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>,
 Edward Cree <ecree.xilinx@...il.com>,
 Alison Schofield <alison.schofield@...el.com>
Subject: Re: [PATCH v17 02/22] sfc: add cxl support


On 7/25/25 23:16, dan.j.williams@...el.com wrote:
> alejandro.lucero-palau@ wrote:
>> From: Alejandro Lucero <alucerop@....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 really. There is an empty efx_cxl_init defined at efx_cxl.h when 
SFC_CXL is not set.


>
> Not a showstopper, so:
>
> Reviewed-by: Dan Williams <dan.j.williams@...el.com>


Thanks!


more comments below.


>
> ...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?
>

Yes. I'll remove it.


>> + */
>> +
>> +#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.


Right, but I have to live with current sfc driver design, and I do not 
think there is a good justification for changing it for this case. But I 
agree the idea is to have such container_of functionality which 
hopefully will be used by other drivers.