[PATCH v4 0/6] arm-mpam: Add basic device tree support for resctrl

[Rob Herring]

On Thu, Nov 05, 2026 at 01:53:47PM +0800, Ping Li wrote:
> Hi Yin,
> 
> Sure. Our memory controller MSC is described as a top-level node.
> The MPAM register window is mapped independently in the SoC (the
> component sits on the DDR egress path rather than being a sub-block
> of a memory-controller DT node), so the node is a direct child of
> the root:
> 
> 	ddr_msc: msc at 2238000 {
> 		compatible = "<vendor>,<soc>-ddr-qos",
> 			     "arm,mpam-memory-controller-msc",
> 			     "arm,mpam-msc";
> 		reg = <0x0 0x02238000 0x0 0x1000>;
> 		arm,not-ready-us = <10>;
> 	};
> 
> The first compatible in the list is for our platform glue; I have
> replaced it with a placeholder here since it is not relevant to the
> binding discussion.
> 
> Notes on the properties, in case they matter for the binding:
> 
> - reg: the MPAM register window. Only a subset of the architectural
>   register space is implemented, so the size is the truncated window.
> - single RIS: the component reports HAS_RIS=0, so there are no
>   ris at N child nodes.
> - no interrupts: the component has no MPAM ESR block, so there is
>   no interrupts property.
> - arm,not-ready-us: 10.
> 
> The verified probe path: the node matches via "arm,mpam-msc", and
> patch 6/8 in v3 classifies it as MPAM_CLASS_MEMORY and treats it as
> accessible from all CPUs, which is exactly the behavior we need.
> 
> One question in return: with the node being a direct child of the
> root rather than a child of a memory-controller node, is that a
> form the binding should cover? If the binding expects the MSC to
> always be a sub-node of a memory controller, we would need the
> top-level form to be allowed as well.

This would be why we're not upstreaming the binding without users. We 
need actual h/w to validate the binding works.

Rob