Re: [PATCH v12 06/12] cxl: Add CXL Device Reset helper
From: Lucero Palau, Alejandro
Date: Fri Sep 25 2026 - 07:25:07 EST
On 24/09/2026 01:45, Jonathan Cameron wrote:
On Tue, 22 Sep 2026 17:20:06 -0700
Srirangan Madhavan <smadhavan@xxxxxxxxxx> wrote:
On 9/11/26 6:26 PM, Jonathan Cameron wrote:Yes, we'd need to sanity check if CXL.cache is active. Probably need to
I did not yet address this in v13 because I did not want to expand the+ if (dvsec < 0)Why do we need them both? Sure that's type 2, but a non
+ return dvsec;
+
+ if (!(cap & PCI_DVSEC_CXL_CACHE_CAPABLE) ||
+ !(cap & PCI_DVSEC_CXL_MEM_CAPABLE))
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.
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.
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, andYes. That should all apply as a type3+ is a just a type 2 that doesn't
restoration infrastrcture) adapted by these patches for cxl_reset also
apply directly for type 3? If so, I can generalize this.
support CXL.cache.
But if Type 3Agreed for anything new that is needed but I'm not sure what that would
requires additional ownership or lifecycle handling, can we please
address that separately?
be.
Jonathan