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.