From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Saravana Kannan" Subject: Re: [PATCH] clk: Use a separate struct for holding init data. Date: Thu, 26 Apr 2012 02:15:31 -0700 (PDT) Message-ID: <52d6cbc0369c91d6b1464ae17c76ff41.squirrel@www.codeaurora.org> References: <1335419936-10881-1-git-send-email-skannan@codeaurora.org> <20120426083924.GE17184@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120426083924.GE17184@pengutronix.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Sascha Hauer Cc: Andrew Lunn , Grant Likely , Saravana Kannan , Jamie Iles , Jeremy Kerr , Mike Turquette , Magnus Damm , Deepak Saxena , linux-arm-kernel@lists.infradead.org, Arnd Bergman , linux-arm-msm@vger.kernel.org, Rob Herring , Russell King , Thomas Gleixner , Richard Zhao , Shawn Guo , Paul Walmsley , Linus Walleij , Mark Brown , Stephen Boyd , linux-kernel@vger.kernel.org, Amit Kucheria List-Id: linux-arm-msm@vger.kernel.org On Thu, April 26, 2012 1:39 am, Sascha Hauer wrote: > On Wed, Apr 25, 2012 at 10:58:56PM -0700, Saravana Kannan wrote: >> Create a struct clk_init_data to hold all data that needs to be passed >> from >> the platfrom specific driver to the common clock framework during clock >> registration. Add a pointer to this struct inside clk_hw. >> >> This has several advantages: >> * Completely hides struct clk from many clock platform drivers and >> static >> clock initialization code that don't care for static initialization of >> the struct clks. >> * For platforms that want to do complete static initialization, it >> removed >> the need to directly mess with the struct clk's fields while still >> allowing to statically allocate struct clk. This keeps the code more >> future proof even if they include clk-private.h. >> * Simplifies the generic clk_register() function and allows adding >> optional >> fields in the future without modifying the function signature. >> * Simplifies the static initialization of clocks on all platforms by >> removing the need for forward delcarations or convoluted macros. > > Can we please stop messing with the function prototypes? So you prefer > passing a struct to clk_register which is fine and yes, it may have > advantages. But do we really need to change the prototype? Why can't we > just add a new function? I thought you were using functions that are specific to the clock type and not the clk_register function. That's pretty much the only reason I left in the other functions. I was trying to reduce the first level of churn for people where had already started using the common clock framework. > I am generally open to do these changes, but we have come to the point > where people actually want to *use* the clock framework instead of > rebasing their stuff onto the latest patches. This is pretty early on in the life of the common clock framework. So, I don't think this clean up is unjustified. Again, I left the other functions as is because people might be using it. -Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755567Ab2DZJPe (ORCPT ); Thu, 26 Apr 2012 05:15:34 -0400 Received: from wolverine01.qualcomm.com ([199.106.114.254]:38585 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754682Ab2DZJPb (ORCPT ); Thu, 26 Apr 2012 05:15:31 -0400 X-IronPort-AV: E=McAfee;i="5400,1158,6692"; a="185081402" Message-ID: <52d6cbc0369c91d6b1464ae17c76ff41.squirrel@www.codeaurora.org> In-Reply-To: <20120426083924.GE17184@pengutronix.de> References: <1335419936-10881-1-git-send-email-skannan@codeaurora.org> <20120426083924.GE17184@pengutronix.de> Date: Thu, 26 Apr 2012 02:15:31 -0700 (PDT) Subject: Re: [PATCH] clk: Use a separate struct for holding init data. From: "Saravana Kannan" To: "Sascha Hauer" Cc: "Saravana Kannan" , "Mike Turquette" , "Arnd Bergman" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, "Andrew Lunn" , "Rob Herring" , "Russell King" , "Jeremy Kerr" , "Thomas Gleixner" , "Paul Walmsley" , "Shawn Guo" , "Jamie Iles" , "Richard Zhao" , "Magnus Damm" , "Mark Brown" , "Linus Walleij" , "Stephen Boyd" , "Amit Kucheria" , "Deepak Saxena" , "Grant Likely" User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Priority: 3 (Normal) Importance: Normal Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, April 26, 2012 1:39 am, Sascha Hauer wrote: > On Wed, Apr 25, 2012 at 10:58:56PM -0700, Saravana Kannan wrote: >> Create a struct clk_init_data to hold all data that needs to be passed >> from >> the platfrom specific driver to the common clock framework during clock >> registration. Add a pointer to this struct inside clk_hw. >> >> This has several advantages: >> * Completely hides struct clk from many clock platform drivers and >> static >> clock initialization code that don't care for static initialization of >> the struct clks. >> * For platforms that want to do complete static initialization, it >> removed >> the need to directly mess with the struct clk's fields while still >> allowing to statically allocate struct clk. This keeps the code more >> future proof even if they include clk-private.h. >> * Simplifies the generic clk_register() function and allows adding >> optional >> fields in the future without modifying the function signature. >> * Simplifies the static initialization of clocks on all platforms by >> removing the need for forward delcarations or convoluted macros. > > Can we please stop messing with the function prototypes? So you prefer > passing a struct to clk_register which is fine and yes, it may have > advantages. But do we really need to change the prototype? Why can't we > just add a new function? I thought you were using functions that are specific to the clock type and not the clk_register function. That's pretty much the only reason I left in the other functions. I was trying to reduce the first level of churn for people where had already started using the common clock framework. > I am generally open to do these changes, but we have come to the point > where people actually want to *use* the clock framework instead of > rebasing their stuff onto the latest patches. This is pretty early on in the life of the common clock framework. So, I don't think this clean up is unjustified. Again, I left the other functions as is because people might be using it. -Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. From mboxrd@z Thu Jan 1 00:00:00 1970 From: skannan@codeaurora.org (Saravana Kannan) Date: Thu, 26 Apr 2012 02:15:31 -0700 (PDT) Subject: [PATCH] clk: Use a separate struct for holding init data. In-Reply-To: <20120426083924.GE17184@pengutronix.de> References: <1335419936-10881-1-git-send-email-skannan@codeaurora.org> <20120426083924.GE17184@pengutronix.de> Message-ID: <52d6cbc0369c91d6b1464ae17c76ff41.squirrel@www.codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, April 26, 2012 1:39 am, Sascha Hauer wrote: > On Wed, Apr 25, 2012 at 10:58:56PM -0700, Saravana Kannan wrote: >> Create a struct clk_init_data to hold all data that needs to be passed >> from >> the platfrom specific driver to the common clock framework during clock >> registration. Add a pointer to this struct inside clk_hw. >> >> This has several advantages: >> * Completely hides struct clk from many clock platform drivers and >> static >> clock initialization code that don't care for static initialization of >> the struct clks. >> * For platforms that want to do complete static initialization, it >> removed >> the need to directly mess with the struct clk's fields while still >> allowing to statically allocate struct clk. This keeps the code more >> future proof even if they include clk-private.h. >> * Simplifies the generic clk_register() function and allows adding >> optional >> fields in the future without modifying the function signature. >> * Simplifies the static initialization of clocks on all platforms by >> removing the need for forward delcarations or convoluted macros. > > Can we please stop messing with the function prototypes? So you prefer > passing a struct to clk_register which is fine and yes, it may have > advantages. But do we really need to change the prototype? Why can't we > just add a new function? I thought you were using functions that are specific to the clock type and not the clk_register function. That's pretty much the only reason I left in the other functions. I was trying to reduce the first level of churn for people where had already started using the common clock framework. > I am generally open to do these changes, but we have come to the point > where people actually want to *use* the clock framework instead of > rebasing their stuff onto the latest patches. This is pretty early on in the life of the common clock framework. So, I don't think this clean up is unjustified. Again, I left the other functions as is because people might be using it. -Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.