Message-ID: <29030d41-3044-4e90-8054-7bf23d12d868@intel.com>
Date: Thu, 29 Jan 2026 09:13:16 -0700
From: Dave Jiang <dave.jiang@...el.com>
To: Robert Richter <rrichter@....com>, dan.j.williams@...el.com
Cc: Alison Schofield <alison.schofield@...el.com>,
 Vishal Verma <vishal.l.verma@...el.com>, Ira Weiny <ira.weiny@...el.com>,
 Jonathan Cameron <jonathan.cameron@...wei.com>,
 Davidlohr Bueso <dave@...olabs.net>, Jonathan Corbet <corbet@....net>,
 linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org,
 Gregory Price <gourry@...rry.net>,
 "Fabio M. De Francesco" <fabio.m.de.francesco@...ux.intel.com>,
 Terry Bowman <terry.bowman@....com>, Joshua Hahn <joshua.hahnjy@...il.com>,
 linux-doc@...r.kernel.org
Subject: Re: [PATCH v4 3/3] Documentation/driver-api/cxl: ACPI PRM Address
 Translation Support and AMD Zen5 enablement



On 1/29/26 3:21 AM, Robert Richter wrote:
> On 28.01.26 11:23:34, dan.j.williams@...el.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.

Hi Robert, if you can get that sent out by tomorrow, lets get your series merged and call it done. Thanks.

> 
> -Robert
> 

Powered by blists - more mailing lists