[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150122185923.GL27202@codeaurora.org>
Date: Thu, 22 Jan 2015 10:59:23 -0800
From: Stephen Boyd <sboyd@...eaurora.org>
To: Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc: linux-kernel@...r.kernel.org,
Mike Turquette <mturquette@...aro.org>,
Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
Paul Walmsley <paul@...an.com>,
Tony Lindgren <tony@...mide.com>,
Russell King <linux@....linux.org.uk>,
linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v11 2/4] clk: Make clk API return per-user struct clk
instances
On 01/22, Tomeu Vizoso wrote:
> On 01/22/2015 02:01 AM, Stephen Boyd wrote:
> > BTW, please try and fixup checkpatch warnings.
>
> What were you thinking of specifically? I'm running it with
> --max-line-length=106 and the other warnings are in clk-test.c that I
> still have to polish when I get some time.
I can see that sometimes we exceed the 80 character limits that
are configured by default. We mostly stick to 80 in this file it
seems so I'm not sure why 106 is being used.
> >
> > And we do it here where we could remove the #ifdef.
>
> Yeah, I tried to reduce the ifdefing back then and this is the simplest
> I could come up with. The reason for clk_get() to call
> __clk_create_clk() directly is that it has more relevant information
> with which to tag the per-user clk.
>
> of_clk_get_by_name() has the name of the node but not the dev_id, which
> in my testing looked as much less useful when debugging who did what to
> a clock.
>
Agreed. But didn't we add __of_clk_get_by_name() so that we could
pass the dev_id and con_id to it? If we did that then all the
relevant information is there and we can call __clk_create_clk()
directly instead of relying on the caller to do it.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists