linux-kernel - RE: [PATCH 1/4] dt-bindings: mfd: aspeed: support for AST2700

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID:
 <OS8PR06MB7541E86C43C2078617A69E2CF28D2@OS8PR06MB7541.apcprd06.prod.outlook.com>
Date: Tue, 20 Aug 2024 06:51:54 +0000
From: Ryan Chen <ryan_chen@...eedtech.com>
To: Andrew Jeffery <andrew@...econstruct.com.au>, Rob Herring
	<robh@...nel.org>
CC: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, Conor Dooley
	<conor+dt@...nel.org>, "linux-aspeed@...ts.ozlabs.org"
	<linux-aspeed@...ts.ozlabs.org>, Stephen Boyd <sboyd@...nel.org>, Michael
 Turquette <mturquette@...libre.com>, Lee Jones <lee@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Krzysztof
 Kozlowski <krzk@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>, "linux-clk@...r.kernel.org"
	<linux-clk@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 1/4] dt-bindings: mfd: aspeed: support for AST2700

> Subject: Re: [PATCH 1/4] dt-bindings: mfd: aspeed: support for AST2700
> 
> On Tue, 2024-08-20 at 01:52 +0000, Ryan Chen wrote:
> > > Subject: Re: [PATCH 1/4] dt-bindings: mfd: aspeed: support for
> > > AST2700
> > >
> > > On Mon, 2024-08-19 at 03:05 +0000, Ryan Chen wrote:
> > > > > > Subject: Re: [PATCH 1/4] dt-bindings: mfd: aspeed: support for
> > > > > > AST2700
> > > > > >
> > > > > > On Wed, 2024-08-14 at 06:35 +0000, Ryan Chen wrote:
> > > > > > > >
> > > > > > > > Didn't I see in another patch one die is cpu and one is
> > > > > > > > io?
> > > > > > > > Use
> > > > > > > > those in the compatible rather than 0 and 1 if so.
> > > > > > > >
> > > > > > > Sorry, I want to align with our datasheet description.
> > > > > > > It will but scu0 and scu1 register setting.
> > > > > >
> > > > > > Can we document that relationship in the binding? Rob's
> > > > > > suggestion seems more descriptive.
> > > > > Hello,
> > > > > 	Do you want me document it in yaml file or just in commit
> > > > > message?
> > > >
> > > > Hello Rob, Andrew,
> > > > 	I will add in yaml file in description. Like following.
> > > >
> > > > description:
> > > >   The Aspeed System Control Unit manages the global behaviour of
> > > > the SoC,
> > > >   configuring elements such as clocks, pinmux, and reset.
> > > > +  In AST2700, it has two soc combination. Each soc include its
> > > > own
> > > > scu register control.
> > > > +  ast2700-scu0 for soc0, ast2700-scu1 for soc1.
> > > >
> > > > Is that will be better way ?
> > >
> > > What Rob is suggesting is to add the compatibles "aspeed,ast2700-
> > > scu-
> > > cpu" and "aspeed,ast2700-scu-io", and then in the description say
> > > something like:
> > >
> > >    The AST2700 integrates both a CPU and an IO die, each with their
> > > own
> > >    SCU. The "aspeed,ast2700-scu-cpu" and "aspeed,ast2700-scu-io"
> > >    compatibles correspond to SCU0 and SCU1 respectively.
> > >
> > Hello Andrew,
> > 	Sorry, for correspond for ast2700 datasheet, the description is
> > scu0/scu1.
> > 	System Control Unit #0 (SCU0)/ System Control Unit #1 (SCU1) why not
> > we
> > 	Keep align with datasheet statement?
> 
> Well, IMO we have an opportunity do better in the compatibles. I expect we
> should take advantage of it. As some support for Rob's suggestion, the
> datasheet chapter for SCU1 calls it "SCUIO" in the first sentence of the
> description. Further, there are only two SCUs, and I don't think the mapping of
> "cpu" to 0 and "io" to 1 is too difficult to keep track of, certainly not if it's
> written in the binding documentation (as long as these names are accurate!).
> The argument works both ways but I don't think it's contentious that using the
> indexes is _less_ descriptive.
> 
> That said, this is just my semi-informed opinion. It's up to you to decide what
> names you're going to push for. Rob's suggestion seems reasonable to me
> though.
> 
Understood, I think I will keep ast2700-scu0,ast2700-scu1, and I will also align with
Our datasheet generates to be consistence. scu0 and scu1.
> Andrew