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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
