Bowman, Terry wrote: [..] > On 8/9/2025 5:56 AM, Alejandro Lucero Palau wrote: > > I come here after Dan suggesting to use this functionality for ensuring > > the CXL device functionality is on, and it would require to inspect the > > status instead of just the capability being present. Maybe I'm confused > > because I remember some patches from Robert Richter dealing with > > checking link up for enabling downstream ports, but I think the goal > > here is different. > > > > Hi Alejandro, > > I agree in large part. We need to check for training complete and any change > in training needs to be reflected in is_cxl(). My understanding is this > will be be added later in a following patch series. > > Dan, can you add your thoughts ? Training completion is implicit in the fact that the device can be targeted by configuration requests. DVSEC 7 absence means you know that CXL is disabled. It is true that DVSEC 7 presence is inconclusive for whether the device supports CXL.mem or CXL.cache. I have seen some implementations hide DVSEC 7, but that can not be relied upon for is_cxl() purposes. CXL.io support is not interesting. So is_cxl() should probably indicate (CXL.mem || CXL.cache) because the presence of those needs CXL subsystem infrastructure.
