Re: [PATCH v4 3/3] Documentation/driver-api/cxl: ACPI PRM Address Translation Support and AMD Zen5 enablement

[Robert Richter <rrichter@amd.com>]

On 28.01.26 11:23:34, dan.j.williams@intel.com wrote:
> Robert Richter wrote:
> [..]
> > the Zen5 machines only use the PRM method as described. They have been
> > out for more than a year now with stable firmware. Moving to _DSM
> > would require a new firmware release and force all of them to run a
> > firmware update.
> 
> Ok, so then do not document _DSM as an option in the convention
> document. Only document what has been shipped and require anything that
> follows to not deviate from that de facto "standard".

Ok, thanks, will update the documentation.

> 
> I was confused by this convention document offering optionality (direct
> PRM or _DSM) and then requiring that the kernel accommodate the less
> preferred option (direct PRM). If there are no plans for the only
> existing implementation in the ecosystem to support _DSM then simply
> require direct PRM forevermore.

Oh, I thought you were aware of the existing PRM implementation and
then wanted me to specify _DSM in the spec, so I started with that.

> 
> > > ...and for the implementation can you update it to only invoke a _DSM
> > > and hide the fact that it might be implemented by PRM on the backend?
> > 
> > Additionally, a kernel implementation change is needed including
> > another test and review cycle. As you described, the implementation on
> > the BIOS side would probably be a _DSM wrapper in AML added to the
> > SSDT that calls the actual PRM handler. An alternative is an ACPI
> > quirk injecting that as AML code, but that makes things worse. IMO,
> > all this is not worth the effort just to define the interface as _DSM
> > only, and then use a wrapper to call it. Plus, there will probably be
> > no platforms that adopt this.
> > 
> > I really would like to see PRM and _DSM coexist in the spec to avoid
> > all that. We could restrict the PRM GUID to the one currently used to
> > avoid other PRM handlers coming up (if platforms adopt this at all).
> > Please consider that.
> 
> No, please no coexistence of alternatives. Direct PRM is shipping, catch
> Linux up with this singular reality, close the door on future changes in
> this space.

Understood.

> 
> If there is ever a "next time" for a different platform concept,
> strongly prefer a static table + native driver enabling approach.

The translation algorithms are not trivial, see around AMD_ATL and in
drivers/ras/amd/atl/. For CXL, PCIe comes into play in addition to
handle that.

Anyway, thanks for your quick response. Will send a v5.

-Robert