On 05/16, Mikko Perttunen wrote: > On 05/15/2015 06:40 PM, Boris Brezillon wrote: > >Hi Stephen, > > > >Adding Mikko in the loop (after all, he was the one complaining about > >this signed long limitation in the first place, and I forgot to add > >him in the Cc list :-/). > > I think I got it through linux-tegra anyway, but thanks :) > > > > >Mikko, are you okay with the approach proposed by Stephen (adding a > >new method) ? > > Yes, sounds good to me. If a driver uses the existing methods with > too large frequencies, the issue is pretty discoverable anyway. I > think "adjust_rate" sounds a bit too much like it sets the clock's > rate, though; perhaps "adjust_rate_request" or something like that? > Well I'm also OK with changing the determine_rate API one more time, but we'll have to be careful. Invariably someone will push a new clock driver through some non-clk tree path and we'll get build breakage. They shouldn't be doing that, so either we do the change now and push it to -next and see what breaks, or we do this after -rc1 comes out and make sure everyone has lots of warning. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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
