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

["Lucero Palau, Alejandro" <alejandro.lucero-palau@amd.com>]

On 25/08/2026 08:37, Lucero Palau, Alejandro wrote:
>
> On 24/08/2026 09:33, Richard Cheng wrote:
>> On Fri, Aug 21, 2026 at 04:51:33PM 
>> +0800,alejandro.lucero-palau@amd.com wrote:
>>> From: Alejandro Lucero<alucerop@amd.com>
>>>
>>> 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>

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