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

[Yin Li <yin.li@oss.qualcomm.com>]

On 11/6/2026 11:08 PM, Rob Herring wrote:
> 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@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@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.
> 

Hi Ping, Rob,

Ping, thank you for the detailed description and for confirming this
on hardware.

To answer your question: the top-level form should be supported.
Unlike cache MSCs, where both class_id and component_id are derived
from the parent cache node, memory controller MSCs derive both from
the MSC node itself via of_node_to_nid(). There is no requirement for
the MSC to be a sub-node of a memory-controller node.

Rob, with Ping's hardware-validated use case covering the top-level
form, we would like to restore memory controller MSC support in v5.
We will use Ping's DT as a reference for the binding example.

Ping, a Tested-by from you would be very welcome once v5 is posted.

Thanks,
Yin


> Rob

-- 
Thx and BRs,
Yin