Re: [RFC 1/2] cxl/memdev: add support for mutipf device

On 25/08/2026 08:37, Lucero Palau, Alejandro wrote:

On 24/08/2026 09:33, Richard Cheng wrote:

quoted

On Fri, Aug 21, 2026 at 04:51:33PM 
+0800,alejandro.lucero-palau@amd.com wrote:

quoted

From: Alejandro Lucero<redacted>

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.

Although this could be handled internally by an accelerator/Type2
driver, it requires to properly handle changes to the CXL mem device,
mainly its release by the CXL core, but also potential CXL device
resets. When this release happens, those other PFs need to be told 
about
it.

Implement a way for non-PF0 PFs to register/unregister to the memdev
linked to the PF0 device. At memdev release, trigger the release of
those non-PF0 PFs devices registered to such memdev from the driver 
they
are bound to.

<snip>

quoted

I suggest replacing cxl_get_pf0_memdev() and cxl_put_pf0_memdev() 
with another
helper, e.g.:

int cxl_memdev_link_consumer(struct device *pf0, struct device 
*consumer, struct range *range);
  It should live in cxl/core/memdev.c , and the behavior is something 
like

1. Find PF0's memdev and take a temp ref.
2. Lock the memdev
3. Verify that the memdev is still registered, driver-bound, 
attached, and has a valid HPA range
4. Create a managed devce link via device_link_add(consumer, 
&cxlmd->dev, DL_FLAG_AUTOREMOVE_CONSUMER);

Interesting approach.


Not sure this could do the proper thing though. 
DL_FLAG_AUTOREMOVE_CONSUMER seems to remove the link, cxlmd->dev in 
your case, when consume driver unbinds ... but it is the other way 
what we need. Maybe I do not understand well all the implications with 
this approach, so let me study it.

I'm having problems just trying to implement the supposedly basic 
functionality linking the cxlmd device with the non-PF0 device, I mean 
without thinking about potential races with this approach (I think it 
has less problems in this regard than my approach).


I can use DL_FLAG_AUTOREMOVE_SUPPLIER with the supplier being 
cxlmd->dev, so at device unbinding it can trigger the non-PF0 device 
unbinding as well. But it seems all this link code is quite related to 
PM, so some checks at link creation fail. I have tried using 
DL_FLAGS_SYNC_STATE_ONLY along with the previous one, but another check 
precludes the link creation if both are used (See 
device_link_flag_is_sync_state_only() ).


Do you have any advice here?

Thanks!

quoted

5. Copy the HPA range
6. Unlock the memdev and drop the temp ref

This helper can return only an error code and the range. The sfc 
driver doesn't need the cxl_memdev pointer then, and
no put helper would be needed.

And driver core would unbind the non-PF0 consumer before unbinding or 
removing the supplier ( memdev ).

I think this can remove the sibling xarray , raw device pointers and 
mutex_trylock() context check.

Would this modle work for your teardown requirements ?

Best regards,
Richard Cheng.