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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <TY2PPF5CB9A1BE6D5DF2D5348DAD6410D42F2F5A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Date: Mon, 20 Oct 2025 08:50:06 +0000
From: Ryan Chen <ryan_chen@...eedtech.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, Lee Jones <lee@...nel.org>, Rob
 Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor
 Dooley <conor+dt@...nel.org>, Joel Stanley <joel@....id.au>, Andrew Jeffery
	<andrew@...econstruct.com.au>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org"
	<linux-aspeed@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells
 range



> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@...nel.org>
> Sent: Monday, October 20, 2025 4:47 PM
> To: Ryan Chen <ryan_chen@...eedtech.com>; Lee Jones <lee@...nel.org>;
> Rob Herring <robh@...nel.org>; Krzysztof Kozlowski <krzk+dt@...nel.org>;
> Conor Dooley <conor+dt@...nel.org>; Joel Stanley <joel@....id.au>; Andrew
> Jeffery <andrew@...econstruct.com.au>; devicetree@...r.kernel.org;
> linux-arm-kernel@...ts.infradead.org; linux-aspeed@...ts.ozlabs.org;
> linux-kernel@...r.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@...000000 {
> > 		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