linux-kernel - Re: [PATCH 2/5] dt-bindings: soc: sophgo: Add Sophgo syscon module

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <PN3P287MB03247B3C149A6C14E5326A23FEB1A@PN3P287MB0324.INDP287.PROD.OUTLOOK.COM>
Date:   Wed, 15 Nov 2023 09:27:09 +0800
From:   Chen Wang <unicorn_wang@...look.com>
To:     Conor Dooley <conor@...nel.org>, Chen Wang <unicornxw@...il.com>
Cc:     aou@...s.berkeley.edu, chao.wei@...hgo.com,
        krzysztof.kozlowski+dt@...aro.org, mturquette@...libre.com,
        palmer@...belt.com, paul.walmsley@...ive.com,
        richardcochran@...il.com, robh+dt@...nel.org, sboyd@...nel.org,
        devicetree@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        haijiao.liu@...hgo.com, xiaoguang.xing@...hgo.com
Subject: Re: [PATCH 2/5] dt-bindings: soc: sophgo: Add Sophgo syscon module


On 2023/11/15 1:40, Conor Dooley wrote:
> On Mon, Nov 13, 2023 at 09:19:02PM +0800, Chen Wang wrote:
>> From: Chen Wang <unicorn_wang@...look.com>
>>
>> Add documentation to describe Sophgo System Controller Registers for
>> SG2042.
>>
>> Signed-off-by: Chen Wang <unicorn_wang@...look.com>
>> ---
>>   .../soc/sophgo/sophgo,sg2042-syscon.yaml      | 38 +++++++++++++++++++
>>   1 file changed, 38 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-syscon.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-syscon.yaml b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-syscon.yaml
>> new file mode 100644
>> index 000000000000..829abede4fd5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-syscon.yaml
>> @@ -0,0 +1,38 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/soc/sophgo/sophgo,sg2042-syscon.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Sophgo SG2042 SoC system controller
>> +
>> +maintainers:
>> +  - Chen Wang <unicorn_wang@...look.com>
>> +
>> +description:
>> +  The Sophgo SG2042 SoC system controller provides register information such
>> +  as offset, mask and shift to configure related modules.
>> +
>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      - items:
>> +          - enum:
>> +              - sophgo,sg2042-syscon
>> +          - const: syscon
> THere's only one option here, so the oneOf should be removed. Similarly,
> since there's only one SoC, and it sounds like the next large sophgo
> system is going to be using an entirely different core provider, I think
> should just simplify this to a pair of "const:" entries.

Yes, "oneOf" should be removed.

Regarding the "enum", I heard from Sophgo people, that they will 
announce a new SG2044 chip next year and it will share some modules from 
SG2042, including syscon, clock ...

So it is better keeping the "enum" here and we may add another 
"sophgo,sg2044-syscon" later.

Regarding the next large sophgo system you mentioned, yes, there is 
anther chip, I think you are talking about SG2380, it will use 
core(P670) from SiFive. Maybe we can see it in next year also.

More news, I find a report from web: 
https://www.hpcwire.com/2023/11/13/chinese-company-developing-64-core-risc-v-chip-with-tech-from-u-s/, 
FYI.


>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    syscon@...10000 {
>> +        compatible = "sophgo,sg2042-syscon", "syscon";
>> +        reg = <0x30010000 0x1000>;
>> +    };
> Per my comments elsewhere, I think the clock controller should be a
> child of this node, rather than an unrelated node, linked by a phandle.

Agree, I will correct this in next revision.


>
> Cheers,
> Conor.