linux-kernel - Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

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] [day] [month] [year] [list]

Date:   Thu, 24 May 2018 15:44:18 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Gilad Ben-Yossef <gilad@...yossef.com>
Cc:     Simon Horman <horms@...ge.net.au>,
        Magnus Damm <magnus.damm@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Ofir Drang <ofir.drang@....com>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad,

On Thu, May 24, 2018 at 3:20 PM, Gilad Ben-Yossef <gilad@...yossef.com> wrote:
> On Tue, May 22, 2018 at 10:48 AM, Geert Uytterhoeven
> <geert@...ux-m68k.org> wrote:
>> On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef <gilad@...yossef.com> wrote:
>>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
>>> <geert@...ux-m68k.org> wrote:
>>>> Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c
>>>> does not distinguish between the absence of the clock property, and an
>>>> actual error in getting the clock, and never considers any error a failure
>>>> (incl. -PROBE_DEFER).
>>>>
>>>> As of_clk_get() returns -ENOENT for both a missing clock property and a
>>>> missing clock, you should use (devm_)clk_get() instead, and distinguish
>>>> between NULL (no clock property) and IS_ERR() (actual failure -> abort).
>>>
>>> I was trying to do as you suggested but I didn't quite get what is the
>>> dev_id (2nd) parameter to devm_clk_get parameter is supposed to be.
>>
>> It's the (optional) name of the clock, helpful in case there is more than one.
>> In your case, NULL is fine.
>
> I have assumed as much and tried it, it did not work and so I assumed
> I am missing something and asked you.
> It turns out I was missing the fact I was using the wrong device tree
> file... :-(
>
> So thanks, it works now :-)

Glad to hear that!

> Having said that, while using devm)clk_get() is a better approach, it
> does not seems to distinguish
> between no "clocks" and a failure to clock information - it returns
> ENOENT in both cases as well.

Oh right, I guess I'm too used to not even getting that far due to the PM
Domain code failing to obtain the clock...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds