Re: [PATCH v3 3/8] dt-bindings: arm: Add MPAM MSC binding

[Rob Herring <robh@kernel.org>]

On Mon, Oct 12, 2026 at 06:24:06PM +0800, Yin Li wrote:
> 
> 
> On 10/12/2026 3:05 PM, Yin Li wrote:
> > 
> > 
> > On 10/9/2026 5:27 AM, Rob Herring wrote:
> > > On Thu, Oct 08, 2026 at 02:41:12PM +0800, Yin Li wrote:
> > > > From: Rob Herring <robh@kernel.org>
> > > > 
> > > > The binding is designed around the assumption that an MSC will be a
> > > > sub-block of something else such as a memory controller, cache
> > > > controller,
> > > > or IOMMU. However, it's certainly possible a design does not have that
> > > > association or has a mixture of both, so the binding illustrates
> > > > how we can
> > > > support that with RIS child nodes.
> > > > 
> > > > A key part of MPAM is we need to know about all of the MSCs in
> > > > the system
> > > > before it can be enabled. This drives the need for the genericish
> > > > 'arm,mpam-msc' compatible. Though we can't assume an MSC is accessible
> > > > until a h/w specific driver potentially enables the h/w.
> > > > 
> > > > Cc: James Morse <james.morse@arm.com>
> > > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > > Signed-off-by: James Morse <james.morse@arm.com>
> > > > [ Yin Li and Huang Yiwei: use oneOf for the compatible to allow both
> > > >    standalone arm,mpam-msc and the two-item combination; fix
> > > > schema field
> > > >    order, type constraints and yamllint spacing; fix example reg
> > > > addresses,
> > > >    add arm,mpam-device phandle and remove TODO comment ]
> > > > Co-developed-by: Huang Yiwei <huang.yiwei@oss.qualcomm.com>
> > > > Signed-off-by: Huang Yiwei <huang.yiwei@oss.qualcomm.com>
> > > > Signed-off-by: Yin Li <yin.li@oss.qualcomm.com>
> > > > ---
> > > >   .../devicetree/bindings/arm/arm,mpam-msc.yaml      | 202
> > > > ++++++++++ +++++++++++
> > > >   1 file changed, 202 insertions(+)
> > > > 
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/arm/arm,mpam-msc.yaml
> > > > b/Documentation/devicetree/bindings/arm/arm,mpam-msc.yaml
> > > > new file mode 100644
> > > > index 000000000000..3c7b13a23ff2
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/arm/arm,mpam-msc.yaml
> > > > @@ -0,0 +1,202 @@
> > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/arm/arm,mpam-msc.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Arm Memory System Resource Partitioning and Monitoring (MPAM)
> > > > +
> > > > +maintainers:
> > > > +  - Rob Herring <robh@kernel.org>
> > > > +
> > > > +description: |
> > > > +  The Arm MPAM specification can be found here:
> > > > +
> > > > +  https://developer.arm.com/documentation/ddi0598/latest
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    oneOf:
> > > > +      - const: arm,mpam-msc                   # Further details
> > > > are discoverable
> > > > +      - items:
> > > > +          - const: arm,mpam-memory-controller-msc
> > > 
> > > Why do we need this?
> > > 
> > 
> > Hi Rob,
> > 
> > Thanks for the review.
> > 
> > The 'arm,mpam-memory-controller-msc' compatible is needed because,
> > unlike cache MSCs, memory controller MSCs cannot rely on the parent node
> > to identify the resource type.
> > 
> > Cache controllers universally carry a 'cache' compatible, so the driver
> > can recognise any cache parent and derive the cache ID from standard
> > properties. No equivalent convention exists for memory controllers, and
> > the component ID comes from the MSC's own 'numa-node-id' rather than the
> > parent, so there is no parent attribute to rely on.
> > 
> 
> Hi Rob,
> 
> As a follow-up to my previous reply:
> Whatever the outcome of the discussion on "arm_mpam: Add support for
> memory controller MSC on DT platforms", we will keep the binding and
> driver support consistent. If it's dropped, the
> 'arm,mpam-memory-controller-msc' compatible, 'numa-node-id' property, and
> the memory controller example will be removed together.

Which parts are you actually using/needing and not using? If you don't 
need RIS support, for example, we should drop it.

Rob