From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87F10C4CECC for ; Sun, 15 Sep 2019 11:14:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 494FE20678 for ; Sun, 15 Sep 2019 11:14:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="VREF9dGM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729693AbfIOLN7 (ORCPT ); Sun, 15 Sep 2019 07:13:59 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:34981 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725997AbfIOLN7 (ORCPT ); Sun, 15 Sep 2019 07:13:59 -0400 Received: by mail-pg1-f194.google.com with SMTP id n4so17692257pgv.2; Sun, 15 Sep 2019 04:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vGC++bKSuV0/ZHeXvOktEZ3piBgJqAASmtSW9gcDz7s=; b=VREF9dGMdMMX6ZJx1pB+O8KiiatL6uIa/VZT40Bvej1Uxn4+9l5TwCceBM8VumPNGw IYwvIX+bR4Kefn3tJkagGe5Umh601Mu2164hRNHeN2YwKkyYufAxkp7Lz0KsDNGux6/h r7sNB9qQDXBK7oqyDiCNOepZf/yeiJHtigS8zLm9B25gsGfwXXZi/TZNLr0CmzjROL+T URTzACd1uGV6/oiT7rRFgiHPEXo/DUAHaZG4+3udlmPyRq+UROkVQ5epJwPxoAJyXSsS pUBFW1TFCjwgpiB0PqGxkCV8Nb3E7neZWclmC6hocMLDz78ALvORvv2iiD4AEeFFb+Vs 76kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vGC++bKSuV0/ZHeXvOktEZ3piBgJqAASmtSW9gcDz7s=; b=si0GabHP4nNlE5ulh+8fCaKQmoG4MPOIyUXvWPD9j52scCMFFMa3j6OlSWcJas99u4 gcIoIOGoZZqux2UrGdBtcSBzwWqiaAEoXHNZ4LZAhb5Z+YV3gQutX4UCJ/BTXko/ZPmM QEp+LJL1Kq1YbAa3nd2U0Zv0aRQMS/wchZc/rfn3g7L+Lt+DR7qovjxHTl4EWtC3Yh3M JkMuhchka1geqS8G3HYSao4CNoveMHTegASrFfR0q0FXIQrR+wK1iQGtAFZ3EOfX/ze5 VrZrU5idGCFMsFvwhDC4trTCcYzjI8qVONUrWdhvhnHgNk/ZTgBz15XaYVueRgpbcS2U 4Yeg== X-Gm-Message-State: APjAAAU/XHABoxpBryBHA9XW9KZJ4nICtb04I5f85I4COEUEu53cmeHs Zzh4Q3SHzbIG2pqjM6xWwTV5Dc93qfaDLgrlJds= X-Google-Smtp-Source: APXvYqyIbP6ZNHGDxbrWlrznhA5vytzdFd4rqRsyaDgTksk3zIWCSt7TuedGEAfBJqPyP8aPmFZbFgaUHJQTX8Qigps= X-Received: by 2002:a17:90b:151:: with SMTP id em17mr8116611pjb.132.1568546038301; Sun, 15 Sep 2019 04:13:58 -0700 (PDT) MIME-Version: 1.0 References: <20190913225547.GA106494@dtor-ws> <20190914170933.GV2680@smile.fi.intel.com> <20190915060524.GC237523@dtor-ws> In-Reply-To: <20190915060524.GC237523@dtor-ws> From: Andy Shevchenko Date: Sun, 15 Sep 2019 14:13:46 +0300 Message-ID: Subject: Re: [PATCH v2] net: mdio: switch to using gpiod_get_optional() To: Dmitry Torokhov Cc: Andy Shevchenko , Andrew Lunn , Florian Fainelli , Heiner Kallweit , "David S. Miller" , Linus Walleij , netdev , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Sep 15, 2019 at 9:26 AM Dmitry Torokhov wrote: > On Sat, Sep 14, 2019 at 08:09:33PM +0300, Andy Shevchenko wrote: > > On Fri, Sep 13, 2019 at 03:55:47PM -0700, Dmitry Torokhov wrote: > > > + mdiodev->reset_gpio = gpiod_get_optional(&mdiodev->dev, > > > + "reset", GPIOD_OUT_LOW); > > > + error = PTR_ERR_OR_ZERO(mdiodev->reset_gpio); > > > + if (error) > > > + return error; > > > + if (mdiodev->reset_gpio) > > > > This is redundant check. > > I see that gpiod_* API handle NULL desc and usually return immediately, > but frankly I am not that comfortable with it. I'm OK with functions > that free/destroy objects that recognize NULL resources, > but it is > unusual for other types of APIs. CLK, reset, ... frameworks do check for NULL pointer since they provide an *_optional() getters. So, it's not unusual. -- With Best Regards, Andy Shevchenko