[PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Ryan Chen]

The #size-cells property in the Aspeed SCU binding is currently
fixed to a constant value of 1. However, newer SoCs (ex. AST2700)
may require two size cells to describe certain subregions or
subdevices.

This patch updates the schema to allow #size-cells values in
the range of 1 to 2. This makes the binding more flexible
while maintaining compatibility with existing platforms.
It also resolves dt-binding validation warnings reported
by `make dt_binding_check`.

Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
 Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
index 5eccd10d95ce..1d3f686577db 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
+++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
@@ -38,7 +38,8 @@ properties:
     maximum: 2
 
   '#size-cells':
-    const: 1
+    minimum: 1
+    maximum: 2
 
   '#clock-cells':
     const: 1
-- 
2.34.1

Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Krzysztof Kozlowski]

On 20/10/2025 04:07, Ryan Chen wrote:
> The #size-cells property in the Aspeed SCU binding is currently
> fixed to a constant value of 1. However, newer SoCs (ex. AST2700)
> may require two size cells to describe certain subregions or

"may"? So there is no issue yet?

> subdevices.
> 
> This patch updates the schema to allow #size-cells values in
> the range of 1 to 2. This makes the binding more flexible
> while maintaining compatibility with existing platforms.
> It also resolves dt-binding validation warnings reported
> by `make dt_binding_check`.

Bu there is a warning? Which warning? On which file?

> 
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
>  Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> index 5eccd10d95ce..1d3f686577db 100644
> --- a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> @@ -38,7 +38,8 @@ properties:
>      maximum: 2
>  
>    '#size-cells':
> -    const: 1
> +    minimum: 1
> +    maximum: 2

That's just enum.

>  
>    '#clock-cells':
>      const: 1


Best regards,
Krzysztof

RE: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Ryan Chen]

> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells
> range
> 
> On 20/10/2025 04:07, Ryan Chen wrote:
> > The #size-cells property in the Aspeed SCU binding is currently fixed
> > to a constant value of 1. However, newer SoCs (ex. AST2700) may
> > require two size cells to describe certain subregions or
> 
> "may"? So there is no issue yet?

while I submit ast2700 platform,
These warnings appear when validating the AST2700 EVB device tree.
The SCU nodes on AST2700 have subdevices (such as clock and reset controllers)
that require two address cells, which is not allowed by the current `const: 1`
constraint in the schema. 

Here is the related report:
  https://lkml.org/lkml/2025/9/2/1165

The errors are:
  arch/arm64/boot/dts/aspeed/ast2700-evb.dtb: syscon@12c02000 (aspeed,ast2700-scu0): #size-cells: 1 was expected
    from schema $id: http://devicetree.org/schemas/mfd/aspeed,ast2x00-scu.yaml#
  arch/arm64/boot/dts/aspeed/ast2700-evb.dtb: syscon@14c02000 (aspeed,ast2700-scu1): '#size-cells' is a required property
    from schema $id: http://devicetree.org/schemas/mfd/aspeed,ast2x00-scu.yaml#


> 
> > subdevices.
> >
> > This patch updates the schema to allow #size-cells values in the range
> > of 1 to 2. This makes the binding more flexible while maintaining
> > compatibility with existing platforms.
> > It also resolves dt-binding validation warnings reported by `make
> > dt_binding_check`.
> 
> Bu there is a warning? Which warning? On which file?
> 
> >
> > Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> > ---
> >  Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > index 5eccd10d95ce..1d3f686577db 100644
> > --- a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > @@ -38,7 +38,8 @@ properties:
> >      maximum: 2
> >
> >    '#size-cells':
> > -    const: 1
> > +    minimum: 1
> > +    maximum: 2
> 
> That's just enum.

Thank advise.
Will use enum: [1, 2] 
> 
> >
> >    '#clock-cells':
> >      const: 1
> 
> 
> Best regards,
> Krzysztof

Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Krzysztof Kozlowski]

On 20/10/2025 08:31, Ryan Chen wrote:
>> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells
>> range
>>
>> On 20/10/2025 04:07, Ryan Chen wrote:
>>> The #size-cells property in the Aspeed SCU binding is currently fixed
>>> to a constant value of 1. However, newer SoCs (ex. AST2700) may
>>> require two size cells to describe certain subregions or
>>
>> "may"? So there is no issue yet?
> 
> while I submit ast2700 platform,

So there is no warning currently? Then don't mention. You cannot use
argument of possible future warning as there is a warning needing to be
fixed. This makes no sense. Like you add bug in your patchset and then
send *different* patch claiming you are fixing a bug.


> These warnings appear when validating the AST2700 EVB device tree.
> The SCU nodes on AST2700 have subdevices (such as clock and reset controllers)
> that require two address cells, which is not allowed by the current `const: 1`
> constraint in the schema. 
> 
> Here is the related report:
>   https://lkml.org/lkml/2025/9/2/1165

This must be together, so we can review entire picture, not pieces by
pieces. Organize your work correctly, so reviewing will be easy.

Best regards,
Krzysztof

Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Krzysztof Kozlowski]

On 20/10/2025 08:39, Krzysztof Kozlowski wrote:
> On 20/10/2025 08:31, Ryan Chen wrote:
>>> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells
>>> range
>>>
>>> On 20/10/2025 04:07, Ryan Chen wrote:
>>>> The #size-cells property in the Aspeed SCU binding is currently fixed
>>>> to a constant value of 1. However, newer SoCs (ex. AST2700) may
>>>> require two size cells to describe certain subregions or
>>>
>>> "may"? So there is no issue yet?
>>
>> while I submit ast2700 platform,
> 
> So there is no warning currently? Then don't mention. You cannot use
> argument of possible future warning as there is a warning needing to be
> fixed. This makes no sense. Like you add bug in your patchset and then
> send *different* patch claiming you are fixing a bug.
> 
> 
>> These warnings appear when validating the AST2700 EVB device tree.
>> The SCU nodes on AST2700 have subdevices (such as clock and reset controllers)
>> that require two address cells, which is not allowed by the current `const: 1`
>> constraint in the schema. 
>>
>> Here is the related report:
>>   https://lkml.org/lkml/2025/9/2/1165
> 
> This must be together, so we can review entire picture, not pieces by
> pieces. Organize your work correctly, so reviewing will be easy.
> 
Anyway, I managed to find your original work and there is no need for
this patch at all. You don't have 64-bit sizes there.

Best regards,
Krzysztof

RE: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Ryan Chen]

> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells
> range
> 
> On 20/10/2025 08:39, Krzysztof Kozlowski wrote:
> > On 20/10/2025 08:31, Ryan Chen wrote:
> >>> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow
> >>> #size-cells range
> >>>
> >>> On 20/10/2025 04:07, Ryan Chen wrote:
> >>>> The #size-cells property in the Aspeed SCU binding is currently
> >>>> fixed to a constant value of 1. However, newer SoCs (ex. AST2700)
> >>>> may require two size cells to describe certain subregions or
> >>>
> >>> "may"? So there is no issue yet?
> >>
> >> while I submit ast2700 platform,
> >
> > So there is no warning currently? Then don't mention. You cannot use
> > argument of possible future warning as there is a warning needing to
> > be fixed. This makes no sense. Like you add bug in your patchset and
> > then send *different* patch claiming you are fixing a bug.
> >
> >
> >> These warnings appear when validating the AST2700 EVB device tree.
> >> The SCU nodes on AST2700 have subdevices (such as clock and reset
> >> controllers) that require two address cells, which is not allowed by
> >> the current `const: 1` constraint in the schema.
> >>
> >> Here is the related report:
> >>   https://lkml.org/lkml/2025/9/2/1165
> >
> > This must be together, so we can review entire picture, not pieces by
> > pieces. Organize your work correctly, so reviewing will be easy.
> >
> Anyway, I managed to find your original work and there is no need for this
> patch at all. You don't have 64-bit sizes there.
Thanks, I will keep #size-cells = <1>; for my next step. 

> 
> Best regards,
> Krzysztof

RE: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Ryan Chen]

> Subject: RE: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells
> range
> 
> > Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow
> > #size-cells range
> >
> > On 20/10/2025 08:39, Krzysztof Kozlowski wrote:
> > > On 20/10/2025 08:31, Ryan Chen wrote:
> > >>> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow
> > >>> #size-cells range
> > >>>
> > >>> On 20/10/2025 04:07, Ryan Chen wrote:
> > >>>> The #size-cells property in the Aspeed SCU binding is currently
> > >>>> fixed to a constant value of 1. However, newer SoCs (ex. AST2700)
> > >>>> may require two size cells to describe certain subregions or
> > >>>
> > >>> "may"? So there is no issue yet?
> > >>
> > >> while I submit ast2700 platform,
> > >
> > > So there is no warning currently? Then don't mention. You cannot use
> > > argument of possible future warning as there is a warning needing to
> > > be fixed. This makes no sense. Like you add bug in your patchset and
> > > then send *different* patch claiming you are fixing a bug.
> > >
> > >
> > >> These warnings appear when validating the AST2700 EVB device tree.
> > >> The SCU nodes on AST2700 have subdevices (such as clock and reset
> > >> controllers) that require two address cells, which is not allowed
> > >> by the current `const: 1` constraint in the schema.
> > >>
> > >> Here is the related report:
> > >>   https://lkml.org/lkml/2025/9/2/1165
> > >
> > > This must be together, so we can review entire picture, not pieces
> > > by pieces. Organize your work correctly, so reviewing will be easy.
> > >
> > Anyway, I managed to find your original work and there is no need for
> > this patch at all. You don't have 64-bit sizes there.
> Thanks, I will keep #size-cells = <1>; for my next step.

Hello Krzysztof,
Sory bothers you again.
After checking the AST2700 platform memory configuration, it supports up to
8GB of DRAM. This requires using `#size-cells = <2>` for the memory node, for
example:

	memory@400000000 {
		device_type = "memory";
		reg = <0x4 0x00000000 0x0 0x40000000>;
	};

Given this, what would be the proper way to proceed?

Thanks again for your guidance.
> 
> >
> > Best regards,
> > Krzysztof

Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Krzysztof Kozlowski]

On 20/10/2025 10:18, Ryan Chen wrote:
>> Subject: RE: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells
>> range
>>
>>> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow
>>> #size-cells range
>>>
>>> On 20/10/2025 08:39, Krzysztof Kozlowski wrote:
>>>> On 20/10/2025 08:31, Ryan Chen wrote:
>>>>>> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow
>>>>>> #size-cells range
>>>>>>
>>>>>> On 20/10/2025 04:07, Ryan Chen wrote:
>>>>>>> The #size-cells property in the Aspeed SCU binding is currently
>>>>>>> fixed to a constant value of 1. However, newer SoCs (ex. AST2700)
>>>>>>> may require two size cells to describe certain subregions or
>>>>>>
>>>>>> "may"? So there is no issue yet?
>>>>>
>>>>> while I submit ast2700 platform,
>>>>
>>>> So there is no warning currently? Then don't mention. You cannot use
>>>> argument of possible future warning as there is a warning needing to
>>>> be fixed. This makes no sense. Like you add bug in your patchset and
>>>> then send *different* patch claiming you are fixing a bug.
>>>>
>>>>
>>>>> These warnings appear when validating the AST2700 EVB device tree.
>>>>> The SCU nodes on AST2700 have subdevices (such as clock and reset
>>>>> controllers) that require two address cells, which is not allowed
>>>>> by the current `const: 1` constraint in the schema.
>>>>>
>>>>> Here is the related report:
>>>>>   https://lkml.org/lkml/2025/9/2/1165
>>>>
>>>> This must be together, so we can review entire picture, not pieces
>>>> by pieces. Organize your work correctly, so reviewing will be easy.
>>>>
>>> Anyway, I managed to find your original work and there is no need for
>>> this patch at all. You don't have 64-bit sizes there.
>> Thanks, I will keep #size-cells = <1>; for my next step.
> 
> Hello Krzysztof,
> Sory bothers you again.
> After checking the AST2700 platform memory configuration, it supports up to
> 8GB of DRAM. This requires using `#size-cells = <2>` for the memory node, for
> example:
> 
> 	memory@400000000 {
> 		device_type = "memory";
> 		reg = <0x4 0x00000000 0x0 0x40000000>;
> 	};
> 
> Given this, what would be the proper way to proceed?


I did not comment on memory node. Maybe I looked at wrong node, not
sure, that's why this should not be discussed here but in that DTS
patchset really.

Best regards,
Krzysztof

RE: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Ryan Chen]

> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Monday, October 20, 2025 4:47 PM
> To: Ryan Chen <ryan_chen@aspeedtech.com>; Lee Jones <lee@kernel.org>;
> Rob Herring <robh@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>; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-aspeed@lists.ozlabs.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells
> range
> 
> On 20/10/2025 10:18, Ryan Chen wrote:
> >> Subject: RE: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow
> >> #size-cells range
> >>
> >>> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow
> >>> #size-cells range
> >>>
> >>> On 20/10/2025 08:39, Krzysztof Kozlowski wrote:
> >>>> On 20/10/2025 08:31, Ryan Chen wrote:
> >>>>>> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow
> >>>>>> #size-cells range
> >>>>>>
> >>>>>> On 20/10/2025 04:07, Ryan Chen wrote:
> >>>>>>> The #size-cells property in the Aspeed SCU binding is currently
> >>>>>>> fixed to a constant value of 1. However, newer SoCs (ex.
> >>>>>>> AST2700) may require two size cells to describe certain
> >>>>>>> subregions or
> >>>>>>
> >>>>>> "may"? So there is no issue yet?
> >>>>>
> >>>>> while I submit ast2700 platform,
> >>>>
> >>>> So there is no warning currently? Then don't mention. You cannot
> >>>> use argument of possible future warning as there is a warning
> >>>> needing to be fixed. This makes no sense. Like you add bug in your
> >>>> patchset and then send *different* patch claiming you are fixing a bug.
> >>>>
> >>>>
> >>>>> These warnings appear when validating the AST2700 EVB device tree.
> >>>>> The SCU nodes on AST2700 have subdevices (such as clock and reset
> >>>>> controllers) that require two address cells, which is not allowed
> >>>>> by the current `const: 1` constraint in the schema.
> >>>>>
> >>>>> Here is the related report:
> >>>>>   https://lkml.org/lkml/2025/9/2/1165
> >>>>
> >>>> This must be together, so we can review entire picture, not pieces
> >>>> by pieces. Organize your work correctly, so reviewing will be easy.
> >>>>
> >>> Anyway, I managed to find your original work and there is no need
> >>> for this patch at all. You don't have 64-bit sizes there.
> >> Thanks, I will keep #size-cells = <1>; for my next step.
> >
> > Hello Krzysztof,
> > Sory bothers you again.
> > After checking the AST2700 platform memory configuration, it supports
> > up to 8GB of DRAM. This requires using `#size-cells = <2>` for the
> > memory node, for
> > example:
> >
> > 	memory@400000000 {
> > 		device_type = "memory";
> > 		reg = <0x4 0x00000000 0x0 0x40000000>;
> > 	};
> >
> > Given this, what would be the proper way to proceed?
> 
> 
> I did not comment on memory node. Maybe I looked at wrong node, not sure,
> that's why this should not be discussed here but in that DTS patchset really.

Understood, thanks for the clarification.
I'll move this discussion to the AST2700 DTS patchset and ensure that the
binding and DTS changes are reviewed together there.

Appreciate your time and guidance.
> 
> Best regards,
> Krzysztof

Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Krzysztof Kozlowski]

On 20/10/2025 10:50, Ryan Chen wrote:
> 
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: Monday, October 20, 2025 4:47 PM
>> To: Ryan Chen <ryan_chen@aspeedtech.com>; Lee Jones <lee@kernel.org>;
>> Rob Herring <robh@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>; devicetree@vger.kernel.org;
>> linux-arm-kernel@lists.infradead.org; linux-aspeed@lists.ozlabs.org;
>> linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells
>> range
>>
>> On 20/10/2025 10:18, Ryan Chen wrote:
>>>> Subject: RE: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow
>>>> #size-cells range
>>>>
>>>>> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow
>>>>> #size-cells range
>>>>>
>>>>> On 20/10/2025 08:39, Krzysztof Kozlowski wrote:
>>>>>> On 20/10/2025 08:31, Ryan Chen wrote:
>>>>>>>> Subject: Re: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow
>>>>>>>> #size-cells range
>>>>>>>>
>>>>>>>> On 20/10/2025 04:07, Ryan Chen wrote:
>>>>>>>>> The #size-cells property in the Aspeed SCU binding is currently
>>>>>>>>> fixed to a constant value of 1. However, newer SoCs (ex.
>>>>>>>>> AST2700) may require two size cells to describe certain
>>>>>>>>> subregions or
>>>>>>>>
>>>>>>>> "may"? So there is no issue yet?
>>>>>>>
>>>>>>> while I submit ast2700 platform,
>>>>>>
>>>>>> So there is no warning currently? Then don't mention. You cannot
>>>>>> use argument of possible future warning as there is a warning
>>>>>> needing to be fixed. This makes no sense. Like you add bug in your
>>>>>> patchset and then send *different* patch claiming you are fixing a bug.
>>>>>>
>>>>>>
>>>>>>> These warnings appear when validating the AST2700 EVB device tree.
>>>>>>> The SCU nodes on AST2700 have subdevices (such as clock and reset
>>>>>>> controllers) that require two address cells, which is not allowed
>>>>>>> by the current `const: 1` constraint in the schema.
>>>>>>>
>>>>>>> Here is the related report:
>>>>>>>   https://lkml.org/lkml/2025/9/2/1165
>>>>>>
>>>>>> This must be together, so we can review entire picture, not pieces
>>>>>> by pieces. Organize your work correctly, so reviewing will be easy.
>>>>>>
>>>>> Anyway, I managed to find your original work and there is no need
>>>>> for this patch at all. You don't have 64-bit sizes there.
>>>> Thanks, I will keep #size-cells = <1>; for my next step.
>>>
>>> Hello Krzysztof,
>>> Sory bothers you again.
>>> After checking the AST2700 platform memory configuration, it supports
>>> up to 8GB of DRAM. This requires using `#size-cells = <2>` for the
>>> memory node, for
>>> example:
>>>
>>> 	memory@400000000 {
>>> 		device_type = "memory";
>>> 		reg = <0x4 0x00000000 0x0 0x40000000>;
>>> 	};
>>>
>>> Given this, what would be the proper way to proceed?
>>
>>
>> I did not comment on memory node. Maybe I looked at wrong node, not sure,
>> that's why this should not be discussed here but in that DTS patchset really.
> 
> Understood, thanks for the clarification.
> I'll move this discussion to the AST2700 DTS patchset and ensure that the
> binding and DTS changes are reviewed together there.
> 

The problem is that you refer to some very old patchset which is long
gone from our mailboxes. Sending a necessary change month after the DTS
patch is not making the discussion easy.

Please always think how your patchset is supposed to be reviewed.

Best regards,
Krzysztof