Re: [PATCH] clk: Use a separate struct for holding init data.

From: Saravana Kannan
Date: Mon Apr 30 2012 - 15:30:38 EST


On 04/26/2012 02:51 AM, Sascha Hauer wrote:
On Thu, Apr 26, 2012 at 02:36:37AM -0700, Saravana Kannan wrote:

On Thu, April 26, 2012 1:42 am, Sascha Hauer wrote:
On Wed, Apr 25, 2012 at 11:28:32PM -0700, Saravana Kannan wrote:

diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 6e58f11..8e97491 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -95,6 +95,7 @@ struct clk *clk_register_mux(struct device *dev,
const char *name,
{

I would really like to remove these functions. At least until we add
device tree support where each clock is listed in device tree.

At present, these functions seem to be abused more than actually
being used appropriately.

I think this goes in my direction. Still exactly this abuse how you call
it makes me relatively independent of for example the changes you
introduce with your patch. Had I static initializers I would now have
to start a rebase orgy.

In the other email you say you have to change. Here you say, you don't
have to change. Hopefully, you didn't have to change much

I don't have to change much, still there are changes since I also use
clk_register. I will do the changes if we agree on your patch, but I
really hope this is the last of such changes.

-- I was aiming for that.

Thank you for this.

If there was agreement about removing these functions, I was
planning on helping move the current users after this patch merged.

Please understand that I begin to get frustrated. I was really happy to
see the clock framework merged in the last window. Now it's -rc4 already
and there are still patches flowing that delay the merge of SoC support.

Mike, Shawn, Paul, Rob,

Comments? Can we pull this in?

-Saravana

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/