On Tue, Aug 27, 2013 at 10:23 AM, Lee Jones <lee.jo...@linaro.org> wrote: > On Fri, 23 Aug 2013, Linus Walleij wrote: >> On Thu, Aug 22, 2013 at 11:21 AM, Lee Jones <lee.jo...@linaro.org> wrote:
>> > 1. Duplicate each of the; clk_reg_prcmu_*(), clk_reg_prcc_pclk(), >> > clk_reg_prcc_kclk() calls into your proposed u8500_clk_init_dt(), >> > which, while keeping everything separate would be unrealistic. >> >> I think this is perfectly realistic. >> >> You're not going to duplicate each clk_register_clkdev(), >> which makes it way smaller than the original function, >> and since one of the function will be inside a >> >> #ifdef CONFIG_OF >> #endif >> >> After we switch the entire platform to DT-only it will be pretty >> obvious which big chunk of code that needs to go away, it's >> a clean cut. >> >> (Note: I know the #ifdef CONFIG_OF is not necessary anymore >> since we switched to multiplatform, but I intend that marker for >> humans, not machines.) > > This sounds gross. To duplicate; u8500_clk_init(), u8540_clk_init() > and u9540_clk_init() just for the sake of loading a few pointers into > an array for a small part of the development cycle sounds obscene. > > I genuinely think keeping the current patch in this series and then > removing the clk_register_clkdev() in the remove ATAG support series > is the best way to go. So what I am worrying about is not only the looks of the code and what is beautiful or not may be something of an opinion anway. What I worry about is leaving all the calls to clk_register_clkdev() in the DT boot path. Because that has the potential to hide a lot of bugs, as clk_get() from drivers that should've got named and probed randomly now will still find their clocks from their old device names, instead of using the <&ersand> clocks from the device tree. But if you still don't like this, let me cook a counter-patch so I can realized on my own how terribly wrong I am... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
