Re: [PATCH v2 0/4] Type2 multipf support

[Alison Schofield <alison.schofield@intel.com>]

On Thu, Oct 01, 2026 at 02:20:19PM +0100, alucerop@amd.com wrote:
> From: Alejandro Lucero <alucerop@amd.com>

Hi Alejandro,

It caught my eye that Patch 1 didn't go to driver-core list, nor GregKH.
This recipient list is not quite right. Appending how I get the list and
what I think your list should look like. Your method may vary but the list
should be same. Okay maybe omit linux-kernel ;)

If this were a HUGE set you might do cover letter to all and then
patches by subsystem but that's not the case here. Just let us all see
them all.

Thanks!

-- Alison


$ git format-patch --stdout HEAD~4 |  perl scripts/get_maintainer.pl --nogit-fallback --no-rolestats
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
"Rafael J. Wysocki" <rafael@kernel.org>
Danilo Krummrich <dakr@kernel.org>
Davidlohr Bueso <dave@stgolabs.net>
Jonathan Cameron <jic23@kernel.org>
Dave Jiang <dave.jiang@intel.com>
Alison Schofield <alison.schofield@intel.com>
Vishal Verma <vishal.l.verma@intel.com>
Dan Williams <djbw@kernel.org>
Ira Weiny <iweiny@kernel.org>
Li Ming <ming.li@zohomail.com>
Edward Cree <ecree.xilinx@gmail.com>
Andrew Lunn <andrew+netdev@lunn.ch>
"David S. Miller" <davem@davemloft.net>
Eric Dumazet <edumazet@kernel.org>
Jakub Kicinski <kuba@kernel.org>
Paolo Abeni <pabeni@redhat.com>
driver-core@lists.linux.dev
linux-kernel@vger.kernel.org
linux-cxl@vger.kernel.org
netdev@vger.kernel.org
linux-net-drivers@amd.com


> 
> Changes since v1:
>  
>  - Simplify drivers core required change
>  - Change name in the new accelerator API function (Dave)
>  - Do not return cxl memdev but int (Dave)
>  - Refactor sfc cxl initialization for the two cases (Jonathan)
>  - Restrict sfc_cxl_map to only mapping (Jonathan)
>  - Addressing some sashiko reports
> 
> A PCI device can present multiple Physical Functions(PFs) but the CXL
> specs restrict to the first one, PF0, the discovery and management of
> CXL capabilities accessed through a PF0 BAR. Other non-PF0 PFs need to
> obtain the CXL.mem range to work with somehow.
> 
> This patchset adds support for getting the CXL HPA range other non-PF0s
> can use based on what PF0 did initialize. This implies CXL for those PFs
> can only be used if PF0 is bound and successfully initialised CXL. This
> needs to cover the potential race between PFs probing where non-PF0s
> will be deferred if the expected CXL is not ready yet. Moreover, those
> PFs can not keep using such CXL memory if PF0 is unbound what can
> happen in different scenarios.
> 
> This first version after the RFC uses device links as proposed by
> Richard Cheng which simplifies the support avoiding specific handling of
> CXL memdev siblings as the RFC did. Using device links needs a change to
> this core kernel functionality for allowing suppliers without power
> management initialised covered in patch 1. The second patch adds a new
> field to cxl_attach_region struct for facilitating the device link using
> the cxl region device where the Type2 memdev is attached to.
> 
> As stated with the RFC:
> 
> the final Type2 basic support was possible once Dan Williams and
> I reached an agreement on how to solve the potential unwinding spenarios
> linked to a cxl memdev object. The actions triggering this unwinding are:
> 
>  - User space unbinding the cxl mem device from the cxl mem driver.
>  - User space removing cxl_acpi module.
>  - User space unbinding Type2/accelerator pci device from its driver.
>  - User space removing Type2/accelerator driver.
> 
> The last two trigger the unwinding from the Type2/accelerator driver
> exit path, while the first two start the unwinding which in turn invoke
> the Type2 driver release from its pci device.
> 
> In any case, the decission was to release the Type2 driver always
> instead of a degraded functionality if CXL.mem is only part of the full
> functionality. This needs to be extended to other non-PF0 PFs, so all
> the scenarios listed above ending up releasing those other PFs as well
> from their drivers.
> 
> I have tested this patchset  with real hardware advertising two PFs and
> under all the scenarios listed, but stressing this requires another
> framework, likely under qemu or adding a new cxl test set.
> 
> The base is vanilla 7.3-rc4.
> 
> Alejandro Lucero (4):
>   driver core: Check for supplier requiring PM at link creation
>   cxl/region: Add region reference in memdev attach
>   cxl/memdev: Add support for multi PF devices
>   sfc: add multipf support
> 
>  drivers/base/core.c                |   2 +-
>  drivers/cxl/core/memdev.c          |  92 ++++++++++++++++++++++++++
>  drivers/cxl/core/region.c          |   1 +
>  drivers/cxl/cxlmem.h               |   2 +
>  drivers/net/ethernet/sfc/efx_cxl.c | 100 ++++++++++++++++++++++++++---
>  include/cxl/cxl.h                  |   2 +
>  6 files changed, 189 insertions(+), 10 deletions(-)
> 
> 
> base-commit: 93f51579e7df248780214094418f205253383cc5
> -- 
> 2.34.1
> 
>