Hi Gilad, On Thu, May 24, 2018 at 3:20 PM, Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> wrote: > On Tue, May 22, 2018 at 10:48 AM, Geert Uytterhoeven > <geert@xxxxxxxxxxxxxx> wrote: >> On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> wrote: >>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven >>> <geert@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx 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