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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5B83C6FA89 for ; Mon, 5 Sep 2022 19:56:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231403AbiIET4M (ORCPT ); Mon, 5 Sep 2022 15:56:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231545AbiIET4K (ORCPT ); Mon, 5 Sep 2022 15:56:10 -0400 Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D240C5C9E4; Mon, 5 Sep 2022 12:56:07 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id u189so39493vsb.4; Mon, 05 Sep 2022 12:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=TxtKuUqRxkHzFdFIsdOfwVRYln8Ru/gjD+KQXu9iPWk=; b=oOTNddka/G5MmOs10MprjSwOych3GIj7p+oXSDb0g7K+MumOQ7dZI9fvJZbh5v/ZDF DkO1HuuP77CxrZ+nX3N/Lzhn/vUJoUctJFw7B5StarCr4bF9V9vn6OWirRi6MzdQqj30 RSw/5Gc1rkcPkllIbByQHmgIVNflrb//j8OILQCPlm+kfxjDVj7A+Lyb1H1czT3F4/xi bz15Ht8yFZoqUyi30wGVEJqKiyzB6caNlhd6ZUpR1ANYxl8eNvELSRuii9PJ3S+s4ley Rp+HaIIqJfxdvV1TQotcVRJ+vu/DyoG1JpVG2rEiNSh0BPI5uNW/2ybVsLc3YOQ/Kl+P cZ2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=TxtKuUqRxkHzFdFIsdOfwVRYln8Ru/gjD+KQXu9iPWk=; b=WCNvLWtUi9w+FeNCZsflRjF0ID4ugtaZ1mWZ96XyT+k5DHV9Hzxmk66CzHhReHP2xQ gslr33mwb7MnynctUuRUVY/jIMPLXnp93aWP5tTFcZb8OHtFoFbykjmaugXEN2xsWeyy ZU/TD1wLGg1a9h1BIGDWIBZhBT5CLt4dhiuT3/LBIYM+a/9f1LQcBPB1SSidHhyB7gGd pOFpzHYLve6Ytr1/ezGFJ83KdKu0QaEPT4lJFxUBsQPKxGJbkfnysEiYxzyryBzy3hIM BQEvVqIlDIgwMLi+vyGnbcM5vKDFUra+ni0bSC3iaYNGyNtALLHIyDynNqerXiLdd72U Sj/w== X-Gm-Message-State: ACgBeo2+3fYXbaK1o8VmPejQWJZuEquxkNw60FOJRn2x0oCmU4yMt6vv PyTMiF1bcNjwSyUPCSQPnLSnxTverdHKRhcUQT4= X-Google-Smtp-Source: AA6agR40buubTfPsstG80DF+s22ldT4F+qiWGt4P8UBWfLfejzg6ynm6XI4ScnPvxtGB0Oeq1Upf5TBcnrM6rSa5o+Y= X-Received: by 2002:a67:e058:0:b0:390:e62d:8976 with SMTP id n24-20020a67e058000000b00390e62d8976mr11716363vsl.31.1662407766752; Mon, 05 Sep 2022 12:56:06 -0700 (PDT) MIME-Version: 1.0 References: <20220903-gpiod_get_from_of_node-remove-v1-0-b29adfb27a6c@gmail.com> <20220903-gpiod_get_from_of_node-remove-v1-4-b29adfb27a6c@gmail.com> In-Reply-To: From: Andy Shevchenko Date: Mon, 5 Sep 2022 22:55:30 +0300 Message-ID: Subject: Re: [PATCH v1 04/11] usb: phy: tegra: switch to using devm_gpiod_get() To: Dmitry Torokhov Cc: Thierry Reding , Mark Brown , Matti Vaittinen , Lorenzo Pieralisi , Claudiu Beznea , Liam Girdwood , Wim Van Sebroeck , Greg Kroah-Hartman , Guenter Roeck , Miquel Raynal , Linus Walleij , Felipe Balbi , Alexandre Belloni , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Vignesh Raghavendra , Daniel Vetter , Thomas Petazzoni , Alexandre Torgue , Marc Zyngier , Richard Weinberger , David Airlie , Nicolas Ferre , Alyssa Rosenzweig , Bartosz Golaszewski , Jonathan Hunter , Rob Herring , Maxime Coquelin , Bjorn Helgaas , =?UTF-8?Q?Pali_Roh=C3=A1r?= , LINUXWATCHDOG , USB , "open list:GPIO SUBSYSTEM" , linux-pci , linux-tegra , "open list:MEMORY TECHNOLOGY..." , Linux Kernel Mailing List , dri-devel , linux-stm32@st-md-mailman.stormreply.com, linux-arm Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-watchdog@vger.kernel.org On Mon, Sep 5, 2022 at 10:51 PM Dmitry Torokhov wrote: > On Mon, Sep 05, 2022 at 10:41:40PM +0300, Andy Shevchenko wrote: > > On Mon, Sep 5, 2022 at 10:40 PM Dmitry Torokhov > > wrote: > > > On Mon, Sep 05, 2022 at 01:59:44PM +0300, Andy Shevchenko wrote: > > > > On Mon, Sep 5, 2022 at 9:32 AM Dmitry Torokhov > > > > wrote: ... > > > > > - gpiod = devm_gpiod_get_from_of_node(&pdev->dev, np, > > > > > - "nvidia,phy-reset-gpio", > > > > > - 0, GPIOD_OUT_HIGH, > > > > > - "ulpi_phy_reset_b"); > > > > > + gpiod = devm_gpiod_get(&pdev->dev, "nvidia,phy-reset", > > > > > + GPIOD_OUT_HIGH); > > > > > err = PTR_ERR_OR_ZERO(gpiod); > > > > > > > > What does _OR_ZERO mean now? > > > > > > This converts a pointer to an error code if a pointer represents > > > ERR_PTR() encoded error, or 0 to indicate success. > > > > Yes, I know that. My point is, how is it useful now (or even before)? > > I mean that devm_gpio_get() never returns NULL, right? > > What does returning NULL have to do with anything. It has to do with a dead code. If defm_gpiod_get() does not return NULL, then why do we even bother to check? > It converts a pointer > to a "classic" return code, with negative errors and 0 on success. > > It allows to not use multiple IS_ERR/PTR_ERR in the code (I'd need 1 > IS_ERR and 2 PTR_ERR, one in dev_err() and another to return). I don't see how this is relevant. -- With Best Regards, Andy Shevchenko