Re: [PATCH v6 3/9] cxl/region: Skip decoder reset on detach for autodiscovered regions

[Alejandro Lucero Palau <alucerop@amd.com>]

On 3/12/26 19:53, Dan Williams wrote:
> Dan Williams wrote:
> [..]
>> All of this wants some documentation to tell users that the rule is
>> "Hey, after any endpoint decoder has been seen by the CXL core, if you
>> remove that endpoint decoder by removing or disabling any of cxl_acpi,
>> cxl_mem, or cxl_port the CXL core *will* violently destroy the decode
>> configuration". Then think about whether this needs a way to specify
>> "skip decoder teardown" to disambiguate "the decoder is disappearing
>> logically, but not physically, keep its configuration". That allows
>> turning any manual configuration into an auto-configuration and has an
>> explicit rule for all regions rather than the current "auto regions are
>> special" policy.
> Do not worry about this paragraph of feedback. I will start a new patch
> set to address this issue. It is the same problem impacting the
> accelerator series where driver reload resets the decode configuration
> by default. Both accelerator drivers and userspace should be able to
> opt-out / opt-in to that behavior.


No, that is not the last accelerator series behavior, and I'm getting 
more than frustrated with all this.


FWIW, Type2 v22 had that behavior, but v23 kept the decoders as BIOS 
configured them ... because you explicitly said that is what it should 
be done.


Now you are saying that should be up to the driver to decide, if I do 
not misunderstand your comment above. And of course, you are going to 
fix that for accelerators! Your patchset will be high priority, just to 
the front of the queue. Understandable, you are the maintainer.


Let me tell you what I think.


You are mentioning the accelerators problem because it suits you. When 
it does not, you usually ignore any type2 support ... until it suits 
you. Of course, I can not tell you when to look at type2 patches, but 
you can not tell me either to not speak up about something seemingly 
arbitrary. I'm defending the kernel upstream process (in general, not 
just inside CXL) internally and it is hard to back that up when I have 
to report what is happening ...


This is my advice (unlikely to be followed): do not write that patchset. 
It is not needed ... now. What is needed is "basic" type2 support in the 
kernel, something as good as possible but not pursuing perfection trying 
to think about all the potential use cases. In other words: usability. 
There will be bugs (hopefully only in corner cases), there will be 
unsupported scenarios, there will likely be misunderstandings of what 
was really needed, but it does not matter the clever you are, you can 
not solve everything now. Guess why: you need people using it with real 
devices and real use cases. If we want CXL to success, what is in our 
hands is to support it as better and as fast as possible for those 
vendors betting on CXL having a chance. Usability, and usability in the 
current scenario where systems with accelerators using CXL will be 
mostly alone regarding other CXL devices. Yes, the future will be 
hopefully more complex and we all working on CXL will be happy then.


Dan, I know you are not only working on CXL, and for avoiding any 
misunderstanding, my rant here is not about your expertise or knowledge. 
It is obvious to anyone reading the mailing list your vision and 
mastering of CXL and kernel CXL support is superb, but I am not happy 
with how you are managing certain aspects of the CXL subsystem/CXL 
community.


This is not the first time I share my frustration, and as when I did so 
in the past, I want to finish with a positive last sentence: I will keep 
trying to get type2 support and hopefully further CXL stuff, and happy 
to discuss the best way to do so with the CXL kernel community.


Thank you


>
> This will want some indication that the root decoder space is designated
> such that it does not get reassigned while the driver is detached.
>