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.
