Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4125881imm; Mon, 30 Jul 2018 09:05:04 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfSmmcQ4dG4BQQhFdk5WVfjJ2KfslaPeqh0gjhj1cUTu8sNCLaVNk67p+SG5yjeQ5f0E/v8 X-Received: by 2002:a62:9541:: with SMTP id p62-v6mr18334199pfd.152.1532966704013; Mon, 30 Jul 2018 09:05:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532966703; cv=none; d=google.com; s=arc-20160816; b=dtSXuwMhnTCDLwQf0Rk+Q5uctbAp/fJa/tEC4fsPU7dwig0kY7WN1x4cJhr3fQjsvb sggguV9YJpBdEHlP/7WvngWAyj8wXl9K9lPlX1aAOHz3VyWfcnWBokt7rd53Va5AKJwF S+QuNxg50ssJtl3UNlOSuOHlDsz8EcUUTodFbZJX2NBo+Q1m6T80yKE1YRflopyNQSws z3lmAwfg8DiUOLlcJP0+GOWuerY4InNynF+7co3lVl3wIjzo4vWXXZrjYVT4EnPcLn0N cagidLMpD/YPT7HSVYFV97wI4sZ+YhtZ12E77lGllTr5LjkQWOUgp0AOQBTT14BxjJJl YPYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=cW52ET9J9JX6RiUeaJT00df4WOfdICEu4+hwfQZARGI=; b=Ey2l0AN1frZoFsEVvS7bbbEix7ZxvcH4OKv0JiZ4wM5gn5G/YNXe/Kv51nmg8Bcm/N 4hRYEGNgScJc8ZdrUAmxxiEHwh3RAHb3gb4rqc8CbZN6i8WZ7LqT2yUeWfFsjazMRovf SlWTmiG1CapzZobj0DVyaFP0gblSuVfx9FxzqywHU5CDPj4HDDW9dLr3s5zUC1U9bOAR 15euKQSeERSI1XRsMhsiYIssiGTxL3MuiMBhFq5NZkbSXTaAZTo5dKriMOB35VhP6lVM iflMTiYYCxtA+fmMuwkDvFPSFXOAdM9M/flRWbD/KS6GWisixn19XCjz5SkEFdJ8uaDC KwJA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u3-v6si11558365pgq.354.2018.07.30.09.04.49; Mon, 30 Jul 2018 09:05:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728666AbeG3RjX (ORCPT + 99 others); Mon, 30 Jul 2018 13:39:23 -0400 Received: from mga09.intel.com ([134.134.136.24]:44581 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726661AbeG3RjX (ORCPT ); Mon, 30 Jul 2018 13:39:23 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2018 09:03:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,422,1526367600"; d="scan'208";a="75777212" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by fmsmga004.fm.intel.com with ESMTP; 30 Jul 2018 09:03:43 -0700 Message-ID: <884376f1fd82a99e5d47eeba1fd1aaa3b19bc604.camel@linux.intel.com> Subject: Re: [PATCH v3 1/2] clk: Add of_clk_get_by_name_optional() function From: Andy Shevchenko To: Phil Edworthy , Michael Turquette , Stephen Boyd , Russell King Cc: Geert Uytterhoeven , Simon Horman , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Date: Mon, 30 Jul 2018 19:03:42 +0300 In-Reply-To: <1532957509-14541-2-git-send-email-phil.edworthy@renesas.com> References: <1532957509-14541-1-git-send-email-phil.edworthy@renesas.com> <1532957509-14541-2-git-send-email-phil.edworthy@renesas.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1-2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2018-07-30 at 14:31 +0100, Phil Edworthy wrote: > Quite a few drivers get an optional clock, e.g. a clock required > to access peripheral's registers that is always enabled on some > devices. > > This function behaves the same as of_clk_get_by_name() except that > it will return NULL instead of -EINVAL. I'm puzzled a bit. __of_clk_get() may return few error codes, and to me ENOENT sounds correct when clock is not found. Other error codes should be passed to the caller even for optional clocks. If above is not true, we need to understand what circumstances for each possible returned code are, and fix / act accordingly. P.S. Possible way like regulator framework does is to return -ENODEV. So, basically what I'm asking here is to be sure that single error code (for now supposed -EINVAL) in this case is _the_ error code for absent / can't be found clock. > - Fix check for clock not present. __of_clk_get() returns -EINVAL > if it's not there. Cover case of when there is no clock name. -- Andy Shevchenko Intel Finland Oy