From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751846Ab3LJUUz (ORCPT ); Tue, 10 Dec 2013 15:20:55 -0500 Received: from cantor2.suse.de ([195.135.220.15]:52313 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751030Ab3LJUUx (ORCPT ); Tue, 10 Dec 2013 15:20:53 -0500 Date: Tue, 10 Dec 2013 21:20:51 +0100 Message-ID: From: Takashi Iwai To: Paul Walmsley Cc: Hans-Christian Egtvedt , Jaroslav Kysela , "alsa-devel@alsa-project.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] ALSA: at73c213: clk_round_rate() can return a zero upon error In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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