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: <073fcd16-12ae-ed4f-5eac-534bf73e68fe@linaro.org>
Date:   Fri, 10 Jun 2022 11:49:57 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Tomer Maimon <tmaimon77@...il.com>
Cc:     Avi Fishman <avifishman70@...il.com>,
        Tali Perry <tali.perry1@...il.com>,
        Joel Stanley <joel@....id.au>,
        Patrick Venture <venture@...gle.com>,
        Nancy Yuen <yuenn@...gle.com>,
        Benjamin Fair <benjaminfair@...gle.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Greg KH <gregkh@...uxfoundation.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Olof Johansson <olof@...om.net>,
        Jiri Slaby <jirislaby@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        Vinod Koul <vkoul@...nel.org>,
        Biju Das <biju.das.jz@...renesas.com>,
        Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>,
        Robert Hancock <robert.hancock@...ian.com>,
        Jonathan Neuschäfer <j.neuschaefer@....net>,
        Lubomir Rintel <lkundrak@...sk>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        LINUXWATCHDOG <linux-watchdog@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 06/20] dt-binding: clk: npcm845: Add binding for
 Nuvoton NPCM8XX Clock

On 09/06/2022 23:21, Tomer Maimon wrote:
> Hi Krzysztof,
> 
> 
> On Thu, 9 Jun 2022 at 16:22, Krzysztof Kozlowski
> <krzysztof.kozlowski@...aro.org> wrote:
>>
>> On 09/06/2022 15:17, Tomer Maimon wrote:
>>> Hi Krzysztof,
>>>
>>> Thanks for your comments.
>>>
>>> On Wed, 8 Jun 2022 at 13:03, Krzysztof Kozlowski
>>> <krzysztof.kozlowski@...aro.org> wrote:
>>>>
>>>> On 08/06/2022 11:56, Tomer Maimon wrote:
>>>>> Add binding for the Arbel BMC NPCM8XX Clock controller.
>>>>>
>>>>> Signed-off-by: Tomer Maimon <tmaimon77@...il.com>
>>>>> ---
>>>>>  .../bindings/clock/nuvoton,npcm845-clk.yaml   | 63 +++++++++++++++++++
>>>>>  .../dt-bindings/clock/nuvoton,npcm8xx-clock.h | 50 +++++++++++++++
>>>>>  2 files changed, 113 insertions(+)
>>>>>  create mode 100644 Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml
>>>>>  create mode 100644 include/dt-bindings/clock/nuvoton,npcm8xx-clock.h
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml b/Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..e1f375716bc5
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml
>>>>> @@ -0,0 +1,63 @@
>>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/clock/nuvoton,npcm845-clk.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: Nuvoton NPCM8XX Clock Controller Binding
>>>>> +
>>>>> +maintainers:
>>>>> +  - Tomer Maimon <tmaimon77@...il.com>
>>>>> +
>>>>> +description: |
>>>>> +  Nuvoton Arbel BMC NPCM8XX contains an integrated clock controller, which
>>>>> +  generates and supplies clocks to all modules within the BMC.
>>>>> +
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    enum:
>>>>> +      - nuvoton,npcm845-clk
>>>>> +
>>>>> +  reg:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  clocks:
>>>>> +    items:
>>>>> +      - description: 25M reference clock
>>>>> +      - description: CPU reference clock
>>>>> +      - description: MC reference clock
>>>>> +
>>>>> +  clock-names:
>>>>> +    items:
>>>>> +      - const: refclk
>>>>> +      - const: sysbypck
>>>>> +      - const: mcbypck
>>>>> +
>>>>
>>>> I asked what is the suffix about and you replied "ck"... ok, so let's
>>>> make clear. This should be:
>>>>
>>>>     items:
>>>>       - const: ref
>>>>       - const: sysbyp
>>>>       - const: mcbyp
>>>>
>>>> or something similar, without the same suffix all over.
>>> The clock names are the same clock name in our spec, this why we
>>> prefer to leave the clock names as is.
>>
>> The naming with useless suffixes does not help. If your spec had
>> "refclk_really_clock_this_is_a_clock" you also would insist on that? It
>> does not make sense.
> Sorry but I don't understand why the clock name cause an issue, we
> prefer it will be the same as in our spec-clock diagram
> BTW, the same naming found in NPCM7XX
> https://elixir.bootlin.com/linux/v5.19-rc1/source/Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.txt#L36

Because the names should not have irrelevant information.
interrupt-names should have "txirq". dma-names should not have "txdma".
clock-names should not have "refclock" or "refclk" because it is
irrelevant duplication. These are bindings, not DTS, so whatever you
have in your spec matters less. DTS is the representation of hardware
and there you can name clocks closer to the spec so it is easier for
you, if that's your preference.

And if your spec has "refclk_really_clock_this_is_a_clock" you still
should not use it.

Anyway, you should discuss it last time when I pointed it out. Instead
my comments were ignored and you decided to send v2. That's not how
discussion works and it will not bring you closer to your point.


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ