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]
Date: Mon, 22 Jan 2024 11:41:28 +0800
From: Chen Wang <unicorn_wang@...look.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 Chen Wang <unicornxw@...il.com>, aou@...s.berkeley.edu, chao.wei@...hgo.com,
 conor@...nel.org, 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, guoren@...nel.org,
 jszhang@...nel.org, inochiama@...look.com, samuel.holland@...ive.com
Subject: Re: [PATCH v8 2/5] dt-bindings: soc: sophgo: Add Sophgo system
 control module


On 2024/1/18 13:29, Chen Wang wrote:
>
> On 2024/1/16 19:37, Chen Wang wrote:
>>
>> On 2024/1/16 18:06, Krzysztof Kozlowski wrote:
>>> On 16/01/2024 08:21, Chen Wang wrote:
>>>> From: Chen Wang <unicorn_wang@...look.com>
>>>>
>>>> Add documentation to describe Sophgo System Control for SG2042.
>>>>
>>>> Signed-off-by: Chen Wang <unicorn_wang@...look.com>
>>>> ---
>>>>   .../soc/sophgo/sophgo,sg2042-sysctrl.yaml     | 46 
>>>> +++++++++++++++++++
>>>>   1 file changed, 46 insertions(+)
>>>>   create mode 100644 
>>>> Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml 
>>>>
>>>>
>>>> diff --git 
>>>> a/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml 
>>>> b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml 
>>>>
>>>> new file mode 100644
>>>> index 000000000000..7b50bb56b4cf
>>>> --- /dev/null
>>>> +++ 
>>>> b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml
>>>> @@ -0,0 +1,46 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: 
>>>> http://devicetree.org/schemas/soc/sophgo/sophgo,sg2042-sysctrl.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Sophgo SG2042 SoC system control
>>>> +
>>>> +maintainers:
>>>> +  - Chen Wang <unicorn_wang@...look.com>
>>>> +
>>>> +description:
>>>> +  The Sophgo system control is a registers block (SYS_CTRL), 
>>>> providing multiple
>>>> +  low level platform functions like chip configuration, clock 
>>>> control, etc.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    const: sophgo,sg2042-sysctrl
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  clock-controller:
>>>> +    # Child node
>>> Drop the comment, it is obvious. It cannot be anything else.
>>>
>>>> +    $ref: /schemas/clock/sophgo,sg2042-sysclk.yaml#
>>>> +    type: object
>>> Why isn't this merged here? You do not need the child node really...
>>> unless the clock inputs are specific to that clock controller and you
>>> will have here more devices? But where are they in such case?
>> I don't see more devices will be included later. It should be ok to 
>> merge them into one.
>
> hi, Krzysztof,
>
> After some double check, I find we will have more devices in 
> system-control. For example, in the SYS_CTRL area, there is also a 
> section of registers used to control the "General Purpose Interrupt". 
> The pcie controller of sg2042 will use this interrupt controller which 
> is defined in SYS_CTRL, we will add it in later work.
>
> Specifically, the distribution (offset) of registers in SYS_CTRL is as 
> follows:
>
> - 0x0C0 ~ 0x0FC: for some PLL clocks :
>
> - ......
>
> - 0x2E0 ~ 0x30C: for General Purpose Interrupt:
>
> - ......
>
> - 0x368 ~ 0x3FC: For some gate clocks
>
> So it seems that it is still necessary to keep the current child node 
> method, and it will also facilitate future expansion.
>
> What do you think, please feel free let me know.
>
> Thanks,
>
> Chen

hi, Krzysztof,

Can you please take a look if you have time, looking forward to your reply.

Thanks,

Chen


>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ