linux-kernel - Re:Re: [PATCH v4 2/4] dt-bindings: mfd: sprd: Add bindings for ums512 global registers

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: <71369ca3.307a.17c7de16354.Coremail.zhanglyra@163.com>
Date:   Thu, 14 Oct 2021 16:18:15 +0800 (CST)
From:   ChunyanZhang <zhanglyra@....com>
To:     "Stephen Boyd" <sboyd@...nel.org>
Cc:     "Chunyan Zhang" <zhang.lyra@...il.com>,
        "Rob Herring" <robh+dt@...nel.org>, linux-clk@...r.kernel.org,
        devicetree@...r.kernel.org, "Baolin Wang" <baolin.wang7@...il.com>,
        "Orson Zhai" <orsonzhai@...il.com>,
        "Chunyan Zhang" <chunyan.zhang@...soc.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re:Re: [PATCH v4 2/4] dt-bindings: mfd: sprd: Add bindings for
 ums512 global registers


Resend this since I forgot to switch to plain text mode :(

At 2021-10-14 14:38:42, "Stephen Boyd" <sboyd@...nel.org> wrote:
>Quoting ChunyanZhang (2021-10-13 19:02:44)
>> At 2021-10-14 09:51:25, "Stephen Boyd" <sboyd@...nel.org> wrote:
>> >Quoting ChunyanZhang (2021-10-13 16:49:40)
>> >> At 2021-10-14 06:04:32, "Stephen Boyd" <sboyd@...nel.org> wrote:
>> >> >Quoting Chunyan Zhang (2021-09-22 23:41:35)
>> >> >> diff --git a/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
>> >> >> +
>> >> >> +examples:
>> >> >> +  - |
>> >> >> +    ap_apb_regs: syscon@...00000 {
>> >> >> +      compatible = "sprd,ums512-glbregs", "syscon", "simple-mfd";
>> >> >> +      reg = <0x71000000 0x3000>;
>> >> >> +      #address-cells = <1>;
>> >> >> +      #size-cells = <1>;
>> >> >> +      ranges = <0 0x71000000 0x3000>;
>> >> >> +
>> >> >> +      clock-controller@0 {
>> >> >> +        compatible = "sprd,ums512-apahb-gate";
>> >> >
>> >> >Why is this a subnode of a syscon and simple-mfd? Why not put the>clock-controller@...00000 directly onto the bus? Does making it a child
>> >> >node help somehow?
>> >> 
>> >> These clocks are at the same register range with global registers. I originally put them directly onto the bus indeed when submitting the patches for SC9863A clocks last year, and it had a private property named 'sprd,syscon' which could provide regmap for these clocks.
>> >> 
>> >> Rob suggested [1] us to make them a child of the syscon, and would not need the private property 'sprd, syscon' then.
>> >
>> >Why do you need to use a syscon? Are the registers shared with some
>> >other driver?
>> 
>> Yes, shared with more than one devices which basically are multimedia devices. You may noticed that these are all gate clocks which are in the global registers ranges and are used to controll the enable status of some devices or some part of devices.
>> 
>

>Where does the multimedia device address space start? I see 0x71000000

It doesn't mean that multimedia device address is in this space, multidedia devices have their own address space actually.
All the registers in this space (started from 0x71000000) are more like controll registers for device power, and they were designed as "global registers".
Some gate clocks are also in global register space, so we make this kind of clocks a subnode of syscon, and clock driver can use regmap which mapped by syscon to avoid remapping the same address space to more than one virtual addresses.

Hope I've made that clear, I'd like to give you an example, but I'm on a long leave and cannot look up the specification right now :(
This is not a new issue, we discussed this when the first time I submitted the patches for sprd clocks IIRC.

>to 0x71002000 is for the clock-controller. Is the multimedia device at
>0x71002000 to 0x71003000? If so they're next to each other but not
>sharing the same register space. Is ap_apb_regs more like a soft macro
>that combines a few clks with some multimedia device?