Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3806364imm; Mon, 30 Jul 2018 03:58:25 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeTBdElppurKhPfFM6WdxbF1yhBbGmt70xIqGVqR7ZKwx8/qLquehtXn24wrIP4BbTSfZMY X-Received: by 2002:a17:902:da4:: with SMTP id 33-v6mr15776924plv.193.1532948305739; Mon, 30 Jul 2018 03:58:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532948305; cv=none; d=google.com; s=arc-20160816; b=Evu1HeZ0IvGDDiFFkdkW/4duOpXZozYQZwNsTgBe3gEJvFHDquVuiXT6CJvZxeIxrB xiX5oaBqu4s/lwaLO5LEF6O0kqvxxFSQCuIx4hHjJxhLCCMpCY/ySxID7CdpQsvZ7afb RVw2UfeMRP+vpljbqEcHlHZQxp96TJjkLARcno+6YcGrulH0rqCi3BawpYfPedto0VuW DQW1pdgW1w2rUj+/F77Q9Sapbmr3u+LHBYVyj5Mnl7QdKwoTLu2yOeKtxB/vSO51IdPQ qG2flIqnZ2e3rzEJZU8cz7WSjfVg1jGFxQI759nxXvPlzy4ocdUfcD4D+rOBuN4xQZ0i tBrQ== 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=Ne9kXNYr76U5/UYUuxKpA645C2fWYuUD3iFZU2Murio=; b=UVz0T+yQZzOosRlG4twRckYynPsATIncp7JCxf0aWF6Hm3DtNXOthyiz+CzljmwS+w oZx+xozhNf12o7jiH6m6SBDHFy6hpb4bDTV5CrBxPkPLpj/owk61niASfQ0zrFrJgtzf E2/9os736YkY5DZqwaKPXjiSN9B7379luK9xzIuTT4uK2Hz4ZQwz9ooXrjsOaxBk7IJR 9r5bBDYFXNyf2M/bymF4MCcpwLDsl5BioWgE0ceP4XmkWKjWCZNL+reZLWSwHQWhMJq2 SHgfLYnx5VBQktbw/UlIqlj+KZeTtz3bM4bWOAV4d1EXtmlaX7rsOagOVOuo/thA3ds+ PEfw== 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 g185-v6si10186978pgc.151.2018.07.30.03.58.11; Mon, 30 Jul 2018 03:58:25 -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 S1727655AbeG3Mbl (ORCPT + 99 others); Mon, 30 Jul 2018 08:31:41 -0400 Received: from mga04.intel.com ([192.55.52.120]:35312 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726685AbeG3Mbl (ORCPT ); Mon, 30 Jul 2018 08:31:41 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2018 03:57:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,422,1526367600"; d="scan'208";a="76698959" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by fmsmga001.fm.intel.com with ESMTP; 30 Jul 2018 03:57:08 -0700 Message-ID: Subject: Re: [PATCH v2 1/2] clk: Add of_clk_get_by_name_optional() function From: Andy Shevchenko To: Geert Uytterhoeven , Phil Edworthy Cc: Michael Turquette , Stephen Boyd , Russell King , Simon Horman , linux-clk , Linux Kernel Mailing List , Linux ARM Date: Mon, 30 Jul 2018 13:57:07 +0300 In-Reply-To: References: <1532939768-7018-1-git-send-email-phil.edworthy@renesas.com> <1532939768-7018-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 10:55 +0200, Geert Uytterhoeven wrote: > On Mon, Jul 30, 2018 at 10:36 AM Phil Edworthy > wrote: > > +struct clk *of_clk_get_by_name_optional(struct device_node *np, > > + const char *name) > > +{ > > + if (!np) > > + return ERR_PTR(-ENOENT); > > Shouldn't this return NULL? > Or let __of_clk_get_by_name() handle that (cfr. above)? > > Hmm, of_clk_get_by_name() has a similar check, while the current > __of_clk_get_by_name() already handle np == NULL, too. This check is needed to prevent NULL pointer dereference below. And I agree that absence of device node should be considered as okay case for optional clock (!CONFIG_OF case, for example). > > + > > + return __of_clk_get_by_name(np, np->full_name, name, true); > > +} -- Andy Shevchenko Intel Finland Oy