Re: [PATCH v12 06/12] cxl: Add CXL Device Reset helper

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

On 24/09/2026 01:45, Jonathan Cameron wrote:
> On Tue, 22 Sep 2026 17:20:06 -0700
> Srirangan Madhavan <smadhavan@nvidia.com> wrote:
>
>> On 9/11/26 6:26 PM, Jonathan Cameron wrote:
>>>> +     if (dvsec < 0)
>>>> +             return dvsec;
>>>> +
>>>> +     if (!(cap & PCI_DVSEC_CXL_CACHE_CAPABLE) ||
>>>> +         !(cap & PCI_DVSEC_CXL_MEM_CAPABLE))
>>> Why do we need them both? Sure that's type 2, but a non
>>> class code matching type3 would I think need the same infrastructure
>>> you are building here. That would have cxl.mem but not cxl.cache
>>> - I think some of the CXL SSD prototypes fit in this category.
>> I did not yet address this in v13 because I did not want to expand the
>> series beyond its original Type 2 scope without settling the expected
>> eligibility policy first.
>>
>> The current check requires both CXL.cache and CXL.mem capability and
>> both protocols to be enabled. The reset sequence currently assumes that
>> CXL.cache is active and performs cache disable, optional writeback, and
>> subsequent cache-policy restoration. This might need change.
> Yes, we'd need to sanity check if CXL.cache is active.  Probably need to
> do that anyway because we might have a situation where the driver code
> isn't done for CXL.cache yet but CXL.mem is in use. I think that's
> the case for Alejandro's device?


Well, not exactly. It is true the driver does not handle CXL.cache, and 
it does not make use of this capability, but the protocol is enabled and 
ready between the device and the upstream port.


I think this can be a bit more complicated since that upstream port 
could need to disable cache as well, what is what I did comment on 
discord yesterday. Current firmware/BIOS does enable CXL.cache between 
them, assuming here an endpoint connected to a root port, so the 
protocol (and the potential and uncontrollable path to host memory) open.


If I am right and we end up disabling CXL.cache in the endpoint and in 
the root port, I think the reset should mimic same paranoic measure 
implying to restore (and I guess to keep/cache beforehand) the upstream 
port cache state.


>> Is the current policies (HDM snapshot, range synchronization, and
>> restoration infrastrcture) adapted by these patches for cxl_reset also
>> apply directly for type 3? If so, I can generalize this.
> Yes. That should all apply as a type3+ is a just a type 2 that doesn't
> support CXL.cache.
>
>> But if Type 3
>> requires additional ownership or lifecycle handling, can we please
>> address that separately?
> Agreed for anything new that is needed but I'm not sure what that would
> be.
>
> Jonathan
>