Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752922AbcDNAk4 (ORCPT ); Wed, 13 Apr 2016 20:40:56 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:38523 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750884AbcDNAkx (ORCPT ); Wed, 13 Apr 2016 20:40:53 -0400 Date: Wed, 13 Apr 2016 17:40:50 -0700 From: Stephen Boyd To: Ralf Baechle Cc: Masahiro Yamada , linux-clk@vger.kernel.org, Michael Turquette , linux-mips@linux-mips.org, linux-sh@vger.kernel.org, Haojian Zhuang , Eric Miao , Hartley Sweeten , Greg Ungerer , Ryan Mallon , Geert Uytterhoeven , Steven Miao , Simon Horman , Wan ZongShun , Rich Felker , Yoshinori Sato , adi-buildroot-devel@lists.sourceforge.net, Russell King , linux-m68k@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Magnus Damm , John Crispin , Haavard Skinnemoen , Hans-Christian Egtvedt , Paul Walmsley , Tony Lindgren , linux-omap@vger.kernel.org, Sekhar Nori , Kevin Hilman Subject: Re: [PATCH v2] clk: let clk_disable() return immediately if clk is NULL or error Message-ID: <20160414004050.GJ14441@codeaurora.org> References: <1459821083-28116-1-git-send-email-yamada.masahiro@socionext.com> <20160408003328.GA14441@codeaurora.org> <20160408100600.GI1668@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160408100600.GI1668@linux-mips.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 604 Lines: 19 On 04/08, Ralf Baechle wrote: > > While your argument makes perfect sense, Many clk_disable implementations > are already doing similar checks, for example: > > arch/arm/mach-davinci/clock.c: > [...] > > So should we go and weed out these checks? Yes, it would be nice to at least make the differing implementations of the clk API consistent. Of course, we should really put our efforts towards getting rid of the non-CCF implementations instead so that there's less confusion overall. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project