Re: [PATCH v5 3/4] clk: introduce the common clock framework

[Shawn Guo <shawn.guo@xxxxxxxxxx>]

On Fri, Mar 16, 2012 at 08:23:57PM -0700, Saravana Kannan wrote:
...
> Hi Mike,
> 
> I already took a quick look at the v7 series, but I thought this
> thread has more relevant context for my response. So, responding
> here.
> 
> I'm with Sascha on creating a clk_internal/clk_initializer and
> removing clk_hw. You had asked about the benefits of his suggestion
> in one of the earlier threads. I'm sure I have told some of these
> reasons I don't like clk_hw, but repeating my points here for others
> to chime in.
> 
> I used to be a huge proponent for using macros for clocks in our
> internal tree. All the clocks were constructed using macros (you
> will see it in the history of tree we publish in CAF). They quickly
> became unreadable when you have several hundreds of clocks. The
> biggest problem is that you can't quickly look at a clock's macro
> and figure out what the register offset or bit mask or shift value
> is. Our eyes/brains aren't meant for quickly parsing the commas and
> finding the n-th field or even remembering what the n-th field of
> each macro corresponds to. If it's actually broken out as fields in
> a struct, it's much easier to read. So, long story short, I think
> the well-intentioned helper macros will make code quite unreadable.
> 
While I second the idea of clk_initializer, using macros is not really
the thing to complain.  You can save using those macro helpers by
calling APIs clk_register_*().  But that does not solve the problem,
because those APIs also have a long argument list to fill.

-- 
Regards,
Shawn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel