Message-ID: <a548d317-887f-4b95-a911-4178eee92f0f@amd.com>
Date: Tue, 1 Jul 2025 17:02:17 +0100
From: Alejandro Lucero Palau <alucerop@....com>
To: Dave Jiang <dave.jiang@...el.com>, alejandro.lucero-palau@....com,
 linux-cxl@...r.kernel.org, netdev@...r.kernel.org, dan.j.williams@...el.com,
 edward.cree@....com, davem@...emloft.net, kuba@...nel.org,
 pabeni@...hat.com, edumazet@...gle.com
Subject: Re: [PATCH v17 10/22] cx/memdev: Indicate probe deferral


On 6/27/25 19:17, Dave Jiang wrote:
>
> On 6/24/25 7:13 AM, alejandro.lucero-palau@....com wrote:
>> From: Alejandro Lucero <alucerop@....com>
>>
>> The first step for a CXL accelerator driver that wants to establish new
>> CXL.mem regions is to register a 'struct cxl_memdev'. That kicks off
>> cxl_mem_probe() to enumerate all 'struct cxl_port' instances in the
>> topology up to the root.
>>
>> If the port driver has not attached yet the expectation is that the
>> driver waits until that link is established. The common cxl_pci driver
>> has reason to keep the 'struct cxl_memdev' device attached to the bus
>> until the root driver attaches. An accelerator may want to instead defer
>> probing until CXL resources can be acquired.
>>
>> Use the @endpoint attribute of a 'struct cxl_memdev' to convey when a
>> accelerator driver probing should be deferred vs failed. Provide that
>> indication via a new cxl_acquire_endpoint() API that can retrieve the
>> probe status of the memdev.
>>
>> Signed-off-by: Alejandro Lucero <alucerop@....com>
>> ---
>>   drivers/cxl/core/memdev.c | 42 +++++++++++++++++++++++++++++++++++++++
>>   drivers/cxl/core/port.c   |  2 +-
>>   drivers/cxl/mem.c         |  7 +++++--
>>   include/cxl/cxl.h         |  2 ++
>>   4 files changed, 50 insertions(+), 3 deletions(-)
>>
<snip>


> Can you please explain how the accelerator driver init path is different in this instance that it requires cxl_mem driver to defer probing? Currently with a type3, the cxl_acpi driver will setup the CXL root, hostbridges and PCI root ports. At that point the memdev driver will enumerate the rest of the ports and attempt to establish the hierarchy. However if cxl_acpi is not done, the mem probe will fail. But, the cxl_acpi probe will trigger a re-probe sequence at the end when it is done. At that point, the mem probe should discover all the necessary ports if things are correct. If the accelerator init path is different, can we introduce some documentation to explain the difference?
>
> Also, it seems as long as port topology is not found, it will always go to deferred probing. At what point do we conclude that things may be missing/broken and we need to fail?
>
> DJ
>
>
>

Hi Dave,


The patch commit comes from Dan's original one, so I'm afraid I can not 
explain it better myself.


I added this patch again after Dan suggesting with cxl_acquire_endpoint 
the initialization by a Type2 can obtain some protection against cxl_mem 
or cxl_acpi being removed. I added later protection or handling against 
this by the sfc driver after initialization. So this is the main reason 
for this patch at least to me.


Regarding the goal from the original patch, being honest, I can not see 
the cxl_acpi problem, although I'm not saying it does not exist. But it 
is quite confusing to me and as I said in another patch regarding probe 
deferral, supporting that option would add complexity to the current sfc 
driver probing. If there exists another workaround for avoiding it, that 
would be the way I prefer to follow.


Adding documentation about all this would definitely help, even without 
the Type2 case.

Powered by blists - more mailing lists