At Tue, 10 Dec 2013 11:46:43 -0800, Paul Walmsley wrote: > > On Mon, 9 Dec 2013, Takashi Iwai wrote: > > > At Mon, 9 Dec 2013 18:40:48 -0800, Paul Walmsley wrote: > >> > >> Treat both negative and zero return values from clk_round_rate() > >> as errors. This is needed since subsequent patches will convert > >> clk_round_rate()'s return value to be an unsigned type, rather > >> than a signed type, since some clock sources can generate rates higher > >> than (2^31)-1 Hz. > > > > Is the behavior "returning zero upon error" already in 3.13? That is, > > should this (and another) patch be taken as a 3.13-fix patch, or it's > > for 3.14? > > It depends on the platform. The Common Clock Framework code returns 0 > upon error right now. But other clock framework implementations, such as > the one used by the Atmel AT91 boards, return negative error codes. And > looking at the mainline code, it looks like the at73c213 chip is most > likely to be used on AT91 boards. > > So if you want to send this patch for v3.13-rc, it's probably justified, > but it's low-priority. v3.14 is also fine. > > I'll be sending some followup patches to the platform maintainers to > change the clock framework code to return 0 upon error. But those can't > be applied until the drivers are fixed, if we want to avoid regressions in > error path handling. So from that point of view, applying these driver > patches in v3.13-rc would mean there is less delay to getting the platform > clock framework fixes upstream :-)
OK, unless any known regressions are reported, I'm inclined to put this for 3.14. Now applied to for-next branch. Thanks! Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
