[PATCH v7 1/3] Documentation: common clk API

[Paul Walmsley]

Hello Saravana,

On Tue, 20 Mar 2012, Saravana Kannan wrote:

> To add a few more thoughts, while I agree with Paul that there is room for
> improvement in the APIs, I think the difference in opinion comes when we ask
> the question:
> 
> "When we eventually refine the APIs in the future to be more expressive, do we
> think that the current APIs can or cannot be made as wrappers around the new
> more expressive APIs?"
> 
> Absolutes are almost never right, so I can't give an absolute answer. 
> But I'm strongly leaning towards "we can" as the answer to the question.  
> That combined with the reasons Nicholas mentioned is why I think the 
> APIs should not be marked as experimental in anyway.

The resistance to documenting that the clock interface is not 
well-defined, and that therefore it is likely to change, and that users 
should not expect it to be stable, is perplexing to me.

Certainly a Kconfig help text change seems trivial enough.  But even the 
resistance to CONFIG_EXPERIMENTAL has been quite surprising to me, given 
that every single defconfig in arch/arm/defconfig sets it:

$ find arch/arm/configs -type f  | wc -l
122
$ fgrep -r CONFIG_EXPERIMENTAL=y arch/arm/configs | wc -l
122
$

(that includes iMX, by the way...)

Certainly, neither Kconfig change is going to prevent us on OMAP from 
figuring out what else is needed to convert our platform to the common 
clock code.  And given the level of enthusiasm on the lists, I don't think 
it's going to prevent many of the other ARM platforms from experimenting 
with the conversion, either.

So it would be interesting to know more about why you (or anyone else) 
perceive that the Kconfig changes would be harmful.


- Paul