From: Billy Tsai <billy_tsai@aspeedtech.com>
To: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>, Lee Jones <lee@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Joel Stanley <joel@jms.id.au>,
Andrew Jeffery <andrew@codeconstruct.com.au>,
Linus Walleij <linusw@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Ryan Chen <ryan_chen@aspeedtech.com>,
Andrew Jeffery <andrew@aj.id.au>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>
Subject: Re: [PATCH v5 2/3] dt-bindings: mfd: aspeed,ast2x00-scu: Describe AST2700 SCU0
Date: Fri, 10 Apr 2026 02:00:28 +0000 [thread overview]
Message-ID: <OSQPR06MB7252443E4B4B7A4EE7CCE4818B592@OSQPR06MB7252.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <20260408133114.GA1938858-robh@kernel.org>
> > > > AST2700 consists of two interconnected SoC instances, each with its own
> > > > System Control Unit (SCU). The SCU0 provides pin control, interrupt
> > > > controllers, clocks, resets, and address-space mappings for the
> > > > Secondary and Tertiary Service Processors (SSP and TSP).
> > > >
> > > > Describe the SSP/TSP address mappings using the standard
> > > > memory-region and memory-region-names properties.
> > > >
> > > > Disallow legacy child nodes that are not present on AST2700, including
> > > > p2a-control and smp-memram. The latter is unnecessary as software can
> > > > access the scratch registers via the SCU syscon.
> > > >
> > > > Also allow the AST2700 SoC0 pin controller to be described as a child
> > > > node of the SCU0, and add an example illustrating the SCU0 layout,
> > > > including reserved-memory, interrupt controllers, and pinctrl.
> > > >
> > > > Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
> > > > ---
> > > > .../bindings/mfd/aspeed,ast2x00-scu.yaml | 117 +++++++++++++++++++++
> > > > 1 file changed, 117 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > > > index a87f31fce019..86d51389689c 100644
> > > > --- a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > > > +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > > > @@ -46,6 +46,9 @@ properties:
> > > > '#reset-cells':
> > > > const: 1
> > > >
> > > > + memory-region: true
> > > > + memory-region-names: true
> >
> > > Missing constraints. From where did you take such syntax (so I can fix
> > > it)?
> >
> > The intention was to constrain these properties conditionally for
> > AST2700 SCU0 as done further down in the patch.
> >
> > I can update the binding so that memory-region and memory-region-names
> > have baseline constraints (e.g. minItems and maxItems), and then refine them in the
> > conditional branches for AST2700SCU0, AST2700SCU1 and others
> >
> > memory-region:
> > minItems: 2
> > maxItems: 3
> > memory-region-names:
> > minItems: 2
> > maxItems: 3
> As of this patch, you don't need that. You can just define the regions
> and names at the top-level. And the conditional schema only needs to
> disallow them for the appropriate case.
Based on your suggestion, I will simplify the schema and define
memory-region and memory-region-names at the top-level without item
constraints, and only disallow them for the non-AST2700 cases.
The updated structure would look like:
memory-region:
description:
Reserved memory regions used by AST2700 SCU to configure
coprocessor address mapping windows.
memory-region-names:
description:
Names corresponding to the AST2700 coprocessor mapping windows
listed in memory-region.
...
- if:
properties:
compatible:
contains:
anyOf:
- const: aspeed,ast2700-scu0
- const: aspeed,ast2700-scu1
then:
patternProperties:
'^p2a-control@[0-9a-f]+$': false
'^smp-memram@[0-9a-f]+$': false
else:
properties:
memory-region: false
memory-region-names: false
Does this match what you had in mind?
Thanks
Billy Tsai
next prev parent reply other threads:[~2026-04-10 2:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 7:31 [PATCH v5 0/3] pinctrl: aspeed: Add AST2700 SoC0 support Billy Tsai
2026-03-31 7:31 ` [PATCH v5 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl Billy Tsai
2026-03-31 7:31 ` [PATCH v5 2/3] dt-bindings: mfd: aspeed,ast2x00-scu: Describe AST2700 SCU0 Billy Tsai
2026-04-01 6:36 ` Krzysztof Kozlowski
2026-04-02 6:14 ` Billy Tsai
2026-04-08 13:31 ` Rob Herring
2026-04-10 2:00 ` Billy Tsai [this message]
2026-03-31 7:31 ` [PATCH v5 3/3] pinctrl: aspeed: Add AST2700 SoC0 support Billy Tsai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=OSQPR06MB7252443E4B4B7A4EE7CCE4818B592@OSQPR06MB7252.apcprd06.prod.outlook.com \
--to=billy_tsai@aspeedtech.com \
--cc=andrew@aj.id.au \
--cc=andrew@codeconstruct.com.au \
--cc=brgl@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=joel@jms.id.au \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=lee@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=robh@kernel.org \
--cc=ryan_chen@aspeedtech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).