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

[Jonathan Cameron]

On Tue, 22 Sep 2026 17:20:06 -0700
Srirangan Madhavan <smadhavan@xxxxxxxxxx> 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?

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

>