[PATCH v7 1/3] Documentation: common clk API
paul at pwsan.com
Wed Mar 21 07:44:01 UTC 2012
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
$ fgrep -r CONFIG_EXPERIMENTAL=y arch/arm/configs | wc -l
(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.
More information about the linaro-dev