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

[<dan.j.williams@intel.com>]

Robert Richter wrote:
> This adds a convention document for the following patch series:
> 
>  cxl: ACPI PRM Address Translation Support and AMD Zen5 enablement
> 
> Version 7 and later:
> 
>  https://lore.kernel.org/linux-cxl/20251114213931.30754-1-rrichter@amd.com/
> 
> Link: https://lore.kernel.org/linux-cxl/20251114213931.30754-1-rrichter@amd.com/
> Reviewed-by: Gregory Price <gourry@gourry.net>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Reviewed-by: Alison Schofield <alison.schofield@intel.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Acked-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Robert Richter <rrichter@amd.com>
> ---
[..]
> +Detailed Description of the Change
> +----------------------------------
> +
> +The following describes the necessary changes to the *CXL 3.2 specification*
> +[#cxl-spec-3.2]_:
> +
> +Add the following paragraph to the end of the section:
> +
> +**8.2.4.20 CXL HDM Decoder Capability Structure**
> +
> +"A device may use an HPA space that is not common to other components of the
> +host domain. The platform is responsible for address translation when crossing
> +HPA spaces. The Operating System must determine the interleaving configuration
> +and perform address translation to the HPA ranges of the HDM decoders as
> +needed. The translation mechanism is host-specific and implementation dependent.
> +
> +The platform may provide an interface that can be used by the Operating System
> +to translate a DPA and determine its corresponding SPA, such as a Platform
> +Runtime Mechanism (PRM) handler or a Device-Specific Method (_DSM).

Optionality is not a standard. Linux does not want to consider different
vendors making different choices. One mechanism per concept is the
expectation.

In this case PRM is an implementation detail behind a _DSM calling
convention. I would much prefer if this implementation did not directly
invoke a PRM handler and was instead always fronted by a _DSM. For
example, one way to avoid the pains of PRM would be to implement it as an
AML method. That is not possible if Linux is directly invoking PRM.

With the change to drop the mention of PRM and just document the _DSM
protocol you can add:

Reviewed-by: Dan Williams <dan.j.williams@intel.com>

...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?