linux-kernel - Re: [PATCH 01/14] dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings

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]

Date:   Wed, 7 Feb 2018 12:03:15 -0600
From:   Rob Herring <robh@...nel.org>
To:     Gabriel FERNANDEZ <gabriel.fernandez@...com>
Cc:     Mark Rutland <mark.rutland@....com>,
        Lee Jones <lee.jones@...aro.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "gabriel.fernandez.st@...il.com" <gabriel.fernandez.st@...il.com>,
        Olivier BIDEAU <olivier.bideau@...com>
Subject: Re: [PATCH 01/14] dt-bindings: Document STM32MP1 Reset Clock
 Controller (RCC) bindings

On Mon, Feb 5, 2018 at 1:01 AM, Gabriel FERNANDEZ
<gabriel.fernandez@...com> wrote:
> Hi Rob,
>
> Thanks for reviewing.
>
>
> On 02/05/2018 07:09 AM, Rob Herring wrote:
>> On Fri, Feb 02, 2018 at 03:03:29PM +0100, gabriel.fernandez@...com wrote:
>>> From: Gabriel Fernandez <gabriel.fernandez@...com>
>>>
>>> The RCC block is responsible of the management of the clock and reset
>>> generation for the complete circuit.
>>>
>>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@...com>
>>> ---
>>>   .../devicetree/bindings/mfd/st,stm32-rcc.txt       | 85 ++++++++++++++++++++++
>>>   1 file changed, 85 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>>> new file mode 100644
>>> index 0000000..28017a1
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>>> @@ -0,0 +1,85 @@
>>> +STMicroelectronics STM32 Peripheral Reset Clock Controller
>>> +==========================================================
>>> +
>>> +The RCC IP is both a reset and a clock controller.
>>> +
>>> +Please also refer to reset.txt for common reset controller binding usage.
>>> +
>>> +Please also refer to clock-bindings.txt for common clock controller
>>> +binding usage.
>>> +
>>> +
>>> +Required properties:
>>> +- compatible: "simple-mfd", "syscon"
>>
>>> +- reg: should be register base and length as documented in the datasheet
>>> +
>>> +- Sub-nodes:
>>> +  - compatible: "st,stm32mp1-rcc-clk"
>>> +    - #clock-cells: 1, device nodes should specify the clock in their
>>> +      "clocks" property, containing a phandle to the clock device node,
>>> +      an index specifying the clock to use.
>>> +
>>> +  - compatible: "st,stm32mp1-rcc-rst"
>>> +    - #reset-cells: Shall be 1
>>> +
>>> +Example:
>>> +    rcc: rcc@...00000 {
>>> +            compatible = "syscon", "simple-mfd";
>>> +            reg = <0x50000000 0x1000>;
>>> +
>>> +            rcc_clk: rcc-clk@...00000 {
>>> +                    #clock-cells = <1>;
>>> +                    compatible = "st,stm32mp1-rcc-clk";
>>> +            };
>>> +
>>> +            rcc_rst: rcc-reset@...00000 {
>> You should not have the same unit-address twice.
>>
>> IMO, this should just be:
>>
>>       rcc: rcc@...00000 {
>>               compatible = "st-stm32mp1-rcc";
>>               reg = <0x50000000 0x1000>;
>>               #clock-cells = <1>;
>>               #reset-cells = <1>;
>>       };
>>
>> There's no reason a node can't provide more than 1 function.
> RCC is an dedicated IP for clocks and resets, but also for power
> management (patches will be sent later)

If there's additional functions, they should be part of the binding
now, not later. bindings should not unnecessarily evolve.

> Then i need to probe 3 drivers with same IP.

Drivers and DT nodes don't have to be 1-1. A parent driver can create
additional child devices.

Also, looking at your existing bindings for RCC IP, it is done as I suggested.

> It's also a way to avoid use of 'CLK_OF_DECLARE_DRIVER' and i need it to
> probe the 3th driver.

Sounds like a Linux problem, not a DT issue.

Rob