linux-kernel - Re: [PATCH v2 12/20] dt-bindings: reset: npcm: Add support for NPCM8XX

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: <CAP6Zq1j=x3OcOPSOjJJmOcze7ziM=oWcKdbYzoHhGnvZipu_UQ@mail.gmail.com>
Date:   Mon, 13 Jun 2022 12:25:05 +0300
From:   Tomer Maimon <tmaimon77@...il.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
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 12/20] dt-bindings: reset: npcm: Add support for NPCM8XX

Hi Krzysztof,

Thanks for your clarification.

We can remove the dt-binding file and use numbers in the DTS,
appreciate if you can answer few additional questions:
1. Do you suggest adding all NPCM reset values to the NPCM reset
document or the reset values should describe in the module
documentation that uses it?
2. Some of the NPCM7XX document modules describe the reset value they
use from the dt-binding for example:
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/iio/adc/nuvoton%2Cnpcm750-adc.yaml#L61
If we remove the NPCM8XX dt-binding file should we describe the
NPCM8XX values in the NPCM-ADC document file?

Best regards,

Tomer

On Fri, 10 Jun 2022 at 12:55, Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> On 10/06/2022 00:05, Tomer Maimon wrote:
> > Hi Krzysztof,
> >
> > Sorry, but I thought the fix is only to add an explanation to the
> > dt-binding file as was done in V2.
> >
> > The NPCM8XX binding is done in the same way as the NPCM7XX and both
> > use the same reset driver and use the same reset method in upstreamed
> > NPCM reset driver.
> >
> > Can you please explain again what you suggest to do?
>
> If you want abstract IDs, they must be abstract, so not representing
> hardware registers. Then they start at 1 and are incremented by 1.
>
> Other option is to skip such IDs entirely and use register
> offsets/addresses directly, like Arnd suggested in linked documents. I
> think he expressed it clearly, so please read his answers which I linked
> in previous discussion.
>
> There is no single reason to store register addresses/values/offsets as
> binding headers. These are not bindings.
>
> Best regards,
> Krzysztof