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 550C7ECAAD5 for ; Tue, 6 Sep 2022 12:31:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239915AbiIFMbM (ORCPT ); Tue, 6 Sep 2022 08:31:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60196 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239968AbiIFMaz (ORCPT ); Tue, 6 Sep 2022 08:30:55 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E144E275C2; Tue, 6 Sep 2022 05:27:46 -0700 (PDT) X-IronPort-AV: E=McAfee;i="6500,9779,10461"; a="296579839" X-IronPort-AV: E=Sophos;i="5.93,294,1654585200"; d="scan'208";a="296579839" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Sep 2022 05:27:45 -0700 X-IronPort-AV: E=Sophos;i="5.93,294,1654585200"; d="scan'208";a="565074197" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Sep 2022 05:27:36 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1oVXfv-00975d-2X; Tue, 06 Sep 2022 15:27:31 +0300 Date: Tue, 6 Sep 2022 15:27:31 +0300 From: Andy Shevchenko To: Guenter Roeck Cc: Dmitry Torokhov , Thierry Reding , Mark Brown , Matti Vaittinen , Lorenzo Pieralisi , Claudiu Beznea , Liam Girdwood , Wim Van Sebroeck , Greg Kroah-Hartman , Miquel Raynal , Linus Walleij , Felipe Balbi , Alexandre Belloni , Krzysztof =?utf-8?Q?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 , Pali =?iso-8859-1?Q?Roh=E1r?= , 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 Subject: Re: [PATCH v1 04/11] usb: phy: tegra: switch to using devm_gpiod_get() Message-ID: 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> <4a0d089d-6ac6-b92e-6ac7-3d3de0144b4b@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4a0d089d-6ac6-b92e-6ac7-3d3de0144b4b@roeck-us.net> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Mon, Sep 05, 2022 at 03:07:48PM -0700, Guenter Roeck wrote: > On 9/5/22 12:55, Andy Shevchenko wrote: > > 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(&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? > > PTR_ERR_OR_ZERO() converts into an error code (if the pointer is an > ERR_PTR) or 0 if it is a real pointer. Its purpose is not to convert > NULL into 0, its purpose is to convert a pointer either into an error > code or 0. That is what is done here, and it is done all over the place > in the kernel. I don't see your problem with it. Care to explain ? > > > > 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. > > You lost me. Really, please explain your problem with PTR_ERR_OR_ZERO(). I don't know what I was thinking about... You, guys, are right, sorry for my noise. -- With Best Regards, Andy Shevchenko