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 11E95C43219 for ; Tue, 18 Jan 2022 12:09:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241343AbiARMJR (ORCPT ); Tue, 18 Jan 2022 07:09:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241334AbiARMJQ (ORCPT ); Tue, 18 Jan 2022 07:09:16 -0500 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CDECC061574 for ; Tue, 18 Jan 2022 04:09:16 -0800 (PST) Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9nHg-0001Dm-Ou; Tue, 18 Jan 2022 13:08:20 +0100 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n9nHT-00AzwP-Do; Tue, 18 Jan 2022 13:08:06 +0100 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1n9nHS-0004EX-Dv; Tue, 18 Jan 2022 13:08:06 +0100 Date: Tue, 18 Jan 2022 13:08:06 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Geert Uytterhoeven Cc: Andrew Lunn , Ulf Hansson , Vignesh Raghavendra , KVM list , "Rafael J. Wysocki" , linux-iio@vger.kernel.org, Linus Walleij , Amit Kucheria , ALSA Development Mailing List , Jaroslav Kysela , Guenter Roeck , Thierry Reding , MTD Maling List , Linux I2C , Miquel Raynal , linux-phy@lists.infradead.org, linux-spi , Jiri Slaby , "David S. Miller" , Khuong Dinh , Florian Fainelli , Matthias Schiffer , Kamal Dasu , Greg Kroah-Hartman , Lee Jones , Bartosz Golaszewski , Daniel Lezcano , Kishon Vijay Abraham I , bcm-kernel-feedback-list , "open list:SERIAL DRIVERS" , Jakub Kicinski , Zhang Rui , platform-driver-x86@vger.kernel.org, Linux PWM List , Robert Richter , Saravanan Sekar , Corey Minyard , Linux PM list , Liam Girdwood , Mauro Carvalho Chehab , John Garry , Peter Korsgaard , William Breathitt Gray , Mark Gross , Hans de Goede , Alex Williamson , Mark Brown , Borislav Petkov , Takashi Iwai , Matthias Brugger , openipmi-developer@lists.sourceforge.net, Andy Shevchenko , Benson Leung , Pengutronix Kernel Team , Linux ARM , linux-edac@vger.kernel.org, Tony Luck , Richard Weinberger , Mun Yew Tham , Eric Auger , netdev , "open list:GPIO SUBSYSTEM" , Cornelia Huck , Linux MMC List , Joakim Zhang , Linux Kernel Mailing List , Linux-Renesas , Sergey Shtylyov , Vinod Koul , James Morse , Zha Qipeng , Sebastian Reichel , Niklas =?utf-8?Q?S=C3=B6derlund?= , linux-mediatek@lists.infradead.org, Brian Norris , Yoshihiro Shimoda Subject: Re: [PATCH 1/2] platform: make platform_get_irq_optional() optional Message-ID: <20220118120806.pbjsat4ulg3vnhsh@pengutronix.de> References: <20220117092444.opoedfcf5k5u6otq@pengutronix.de> <20220117114923.d5vajgitxneec7j7@pengutronix.de> <20220117170609.yxaamvqdkivs56ju@pengutronix.de> <20220118090913.pjumkq4zf4iqtlha@pengutronix.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2svqigojwuu4sr3n" Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-gpio@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org --2svqigojwuu4sr3n Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Geert, On Tue, Jan 18, 2022 at 10:37:25AM +0100, Geert Uytterhoeven wrote: > On Tue, Jan 18, 2022 at 10:09 AM Uwe Kleine-K=F6nig > wrote: > > For the (clk|gpiod|regulator)_get_optional() you don't have to check > > against the magic not-found value (so no implementation detail magic > > leaks into the caller code) and just pass it to the next API function. > > (And my expectation would be that if you chose to represent not-found by > > (void *)66 instead of NULL, you won't have to adapt any user, just the > > framework internal checks. This is a good thing!) >=20 > Ah, there is the wrong assumption: drivers sometimes do need to know > if the resource was found, and thus do need to know about (void *)66, > -ENODEV, or -ENXIO. I already gave examples for IRQ and clk before. > I can imagine these exist for gpiod and regulator, too, as soon as > you go beyond the trivial "enable" and "disable" use-cases. My premise is that every user who has to check for "not found" explicitly should not use (clk|gpiod)_get_optional() but (clk|gpiod)_get() and do proper (and explicit) error handling for -ENODEV. (clk|gpiod)_get_optional() is only for these trivial use-cases. > And 0/NULL vs. > 0 is the natural check here: missing, but not > an error. For me it it 100% irrelevant if "not found" is an error for the query function or not. I just have to be able to check for "not found" and react accordingly. And adding a function def platform_get_irq_opional(): ret =3D platform_get_irq() if ret =3D=3D -ENXIO: return 0 return ret it's not a useful addition to the API if I cannot use 0 as a dummy because it doesn't simplify the caller enough to justify the additional function. The only thing I need to be able is to distinguish the cases "there is an irq", "there is no irq" and anything else is "there is a problem I cannot handle and so forward it to my caller". The semantic of platform_get_irq() is able to satisfy this requirement[1], so why introduce platform_get_irq_opional() for the small advantage that I can check for not-found using if (!irq) instead of if (irq !=3D -ENXIO) ? The semantic of platform_get_irq() is easier ("Either a usable non-negative irq number or a negative error number") compared to platform_get_irq_optional() ("Either a usable positive irq number or a negative error number or 0 meaning not found"). Usage of platform_get_irq() isn't harder or more expensive (neither for a human reader nor for a maching running the resulting compiled code). For a human reader if (irq !=3D -ENXIO) is even easier to understand because for if (!irq) they have to check where the value comes from, see it's platform_get_irq_optional() and understand that 0 means not-found. This function just adds overhead because as a irq framework user I have to understand another function. For me the added benefit is too small to justify the additional function. And you break out-of-tree drivers. These are all no major counter arguments, but as the advantage isn't major either, they still matter. Best regards Uwe [1] the only annoying thing is the error message. --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --2svqigojwuu4sr3n Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAmHmraMACgkQwfwUeK3K 7Ak1qwf6Am8XN0nqXfS0pbngp7EaV4pL4oNS8RQxKSvsObY254xYZ+ARuc9D/qcI /twFVp0MmVPlJHmpEM8KLdVakfXpJlaJRkoNiXFxGO6FJGbPNXIQvl33fM4L9u3c k8jyDoz2mdmZdpc6JSLgLroVyQXOl/WygxRbgqO0WCHu762nPfCuaaKUb2yzQ0I1 m+08eRtqVh8WqbbOHrpIhcpfPYzkCeRiGeaqGkO5YwvqeH6kv6eudm8RkAfo6DE9 IwzIaWANKnEqD3UzsSUPdPTmMPfqWML7RJPs6sZCdumiS+Ox36ZGrc7Ewn2ffU/V Q83qyxKFK+RfjJQmmPycReC6KM89bw== =RHyZ -----END PGP SIGNATURE----- --2svqigojwuu4sr3n-- 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 65E34C433EF for ; Tue, 18 Jan 2022 12:10:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=egX6865/6K4YetpFy0fNb5GKeLWlyZQqQf5ovZQdCfw=; b=txW7EEZUOjhtTfhDWGwRvYfCij hN4NltYkjTIGNjT4ZhVWJ1HPDmUTg/BXZvDR3k8YptHtYkO1fcQLZKweFQUbb8bLizydS5sfd3GWq WzU/Z7PvU55EU0qOTdgSK//dZ5CAFyyg5OFSP2/MRTQ/9c8+jGEIflznd2FQI2FEte2vfHKLL9Sbb WimNct63gfAnZ75NAZcNH0F+ONFxk4u6UJg/r6aZidYAJ8dwm+N2SqJx6GxRabPASMsYFkaMG4SNE nwFiReTlcF/QasYqAu7IBOdYJSCUFKFOeZW9JBVFB0MON1kz6MX2l3t31bS3uHEIuTXlqIolugXuV fe2kjy6Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9nJ4-001S2K-Ky; Tue, 18 Jan 2022 12:09:46 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9nJ1-001S1T-5s for linux-mtd@lists.infradead.org; Tue, 18 Jan 2022 12:09:44 +0000 Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9nHg-0001Dm-Ou; Tue, 18 Jan 2022 13:08:20 +0100 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n9nHT-00AzwP-Do; Tue, 18 Jan 2022 13:08:06 +0100 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1n9nHS-0004EX-Dv; Tue, 18 Jan 2022 13:08:06 +0100 Date: Tue, 18 Jan 2022 13:08:06 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Geert Uytterhoeven Cc: Andrew Lunn , Ulf Hansson , Vignesh Raghavendra , KVM list , "Rafael J. Wysocki" , linux-iio@vger.kernel.org, Linus Walleij , Amit Kucheria , ALSA Development Mailing List , Jaroslav Kysela , Guenter Roeck , Thierry Reding , MTD Maling List , Linux I2C , Miquel Raynal , linux-phy@lists.infradead.org, linux-spi , Jiri Slaby , "David S. Miller" , Khuong Dinh , Florian Fainelli , Matthias Schiffer , Kamal Dasu , Greg Kroah-Hartman , Lee Jones , Bartosz Golaszewski , Daniel Lezcano , Kishon Vijay Abraham I , bcm-kernel-feedback-list , "open list:SERIAL DRIVERS" , Jakub Kicinski , Zhang Rui , platform-driver-x86@vger.kernel.org, Linux PWM List , Robert Richter , Saravanan Sekar , Corey Minyard , Linux PM list , Liam Girdwood , Mauro Carvalho Chehab , John Garry , Peter Korsgaard , William Breathitt Gray , Mark Gross , Hans de Goede , Alex Williamson , Mark Brown , Borislav Petkov , Takashi Iwai , Matthias Brugger , openipmi-developer@lists.sourceforge.net, Andy Shevchenko , Benson Leung , Pengutronix Kernel Team , Linux ARM , linux-edac@vger.kernel.org, Tony Luck , Richard Weinberger , Mun Yew Tham , Eric Auger , netdev , "open list:GPIO SUBSYSTEM" , Cornelia Huck , Linux MMC List , Joakim Zhang , Linux Kernel Mailing List , Linux-Renesas , Sergey Shtylyov , Vinod Koul , James Morse , Zha Qipeng , Sebastian Reichel , Niklas =?utf-8?Q?S=C3=B6derlund?= , linux-mediatek@lists.infradead.org, Brian Norris , Yoshihiro Shimoda Subject: Re: [PATCH 1/2] platform: make platform_get_irq_optional() optional Message-ID: <20220118120806.pbjsat4ulg3vnhsh@pengutronix.de> References: <20220117092444.opoedfcf5k5u6otq@pengutronix.de> <20220117114923.d5vajgitxneec7j7@pengutronix.de> <20220117170609.yxaamvqdkivs56ju@pengutronix.de> <20220118090913.pjumkq4zf4iqtlha@pengutronix.de> MIME-Version: 1.0 In-Reply-To: X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-mtd@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220118_040943_436666_2BED2BC2 X-CRM114-Status: GOOD ( 33.99 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5012686346134900460==" Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org --===============5012686346134900460== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2svqigojwuu4sr3n" Content-Disposition: inline --2svqigojwuu4sr3n Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Geert, On Tue, Jan 18, 2022 at 10:37:25AM +0100, Geert Uytterhoeven wrote: > On Tue, Jan 18, 2022 at 10:09 AM Uwe Kleine-K=F6nig > wrote: > > For the (clk|gpiod|regulator)_get_optional() you don't have to check > > against the magic not-found value (so no implementation detail magic > > leaks into the caller code) and just pass it to the next API function. > > (And my expectation would be that if you chose to represent not-found by > > (void *)66 instead of NULL, you won't have to adapt any user, just the > > framework internal checks. This is a good thing!) >=20 > Ah, there is the wrong assumption: drivers sometimes do need to know > if the resource was found, and thus do need to know about (void *)66, > -ENODEV, or -ENXIO. I already gave examples for IRQ and clk before. > I can imagine these exist for gpiod and regulator, too, as soon as > you go beyond the trivial "enable" and "disable" use-cases. My premise is that every user who has to check for "not found" explicitly should not use (clk|gpiod)_get_optional() but (clk|gpiod)_get() and do proper (and explicit) error handling for -ENODEV. (clk|gpiod)_get_optional() is only for these trivial use-cases. > And 0/NULL vs. > 0 is the natural check here: missing, but not > an error. For me it it 100% irrelevant if "not found" is an error for the query function or not. I just have to be able to check for "not found" and react accordingly. And adding a function def platform_get_irq_opional(): ret =3D platform_get_irq() if ret =3D=3D -ENXIO: return 0 return ret it's not a useful addition to the API if I cannot use 0 as a dummy because it doesn't simplify the caller enough to justify the additional function. The only thing I need to be able is to distinguish the cases "there is an irq", "there is no irq" and anything else is "there is a problem I cannot handle and so forward it to my caller". The semantic of platform_get_irq() is able to satisfy this requirement[1], so why introduce platform_get_irq_opional() for the small advantage that I can check for not-found using if (!irq) instead of if (irq !=3D -ENXIO) ? The semantic of platform_get_irq() is easier ("Either a usable non-negative irq number or a negative error number") compared to platform_get_irq_optional() ("Either a usable positive irq number or a negative error number or 0 meaning not found"). Usage of platform_get_irq() isn't harder or more expensive (neither for a human reader nor for a maching running the resulting compiled code). For a human reader if (irq !=3D -ENXIO) is even easier to understand because for if (!irq) they have to check where the value comes from, see it's platform_get_irq_optional() and understand that 0 means not-found. This function just adds overhead because as a irq framework user I have to understand another function. For me the added benefit is too small to justify the additional function. And you break out-of-tree drivers. These are all no major counter arguments, but as the advantage isn't major either, they still matter. Best regards Uwe [1] the only annoying thing is the error message. --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --2svqigojwuu4sr3n Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAmHmraMACgkQwfwUeK3K 7Ak1qwf6Am8XN0nqXfS0pbngp7EaV4pL4oNS8RQxKSvsObY254xYZ+ARuc9D/qcI /twFVp0MmVPlJHmpEM8KLdVakfXpJlaJRkoNiXFxGO6FJGbPNXIQvl33fM4L9u3c k8jyDoz2mdmZdpc6JSLgLroVyQXOl/WygxRbgqO0WCHu762nPfCuaaKUb2yzQ0I1 m+08eRtqVh8WqbbOHrpIhcpfPYzkCeRiGeaqGkO5YwvqeH6kv6eudm8RkAfo6DE9 IwzIaWANKnEqD3UzsSUPdPTmMPfqWML7RJPs6sZCdumiS+Ox36ZGrc7Ewn2ffU/V Q83qyxKFK+RfjJQmmPycReC6KM89bw== =RHyZ -----END PGP SIGNATURE----- --2svqigojwuu4sr3n-- --===============5012686346134900460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ --===============5012686346134900460==-- 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CB540C433EF for ; Tue, 18 Jan 2022 12:10:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=CqmLB4m07p5tUPTRKPrgC9pV/dSlHJYPIENX9BYgx9Q=; b=RFV7srYYXakOZd4yY1sddijY9Q UuL7IrRwbJj8BvKJjApWJe02Bq6YwMMIudXOTD6i4UALIaPTkAbVCC88h4be99rjQYPUKslVmObSZ vwXr7/bJsxU08Ic/2dVHgr3l3YZ2d/j26IYQ/yQqFz+9mWYZhG1CyCmeMPeCMC/9WczznXyHZlAxi f+vthpK+3HwOSfcdatZKXZ6jsmKbOCndA4hUifsfnA6Td9ppACQOaZNVQwfrLoI6YCt7dWOUvzjvJ /zHaos/lOBxOJ/pSMec48XU9wbsAN7UP51C25X5USNsQ/BsnGbZOP5gFPkQkk0d92eAFbkCAMoIfj hpwImCvg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9nJG-001S3C-Vm; Tue, 18 Jan 2022 12:09:59 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9nJ4-001S29-8b for linux-mediatek@lists.infradead.org; Tue, 18 Jan 2022 12:09:48 +0000 Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9nHg-0001Dm-Ou; Tue, 18 Jan 2022 13:08:20 +0100 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n9nHT-00AzwP-Do; Tue, 18 Jan 2022 13:08:06 +0100 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1n9nHS-0004EX-Dv; Tue, 18 Jan 2022 13:08:06 +0100 Date: Tue, 18 Jan 2022 13:08:06 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Geert Uytterhoeven Cc: Andrew Lunn , Ulf Hansson , Vignesh Raghavendra , KVM list , "Rafael J. Wysocki" , linux-iio@vger.kernel.org, Linus Walleij , Amit Kucheria , ALSA Development Mailing List , Jaroslav Kysela , Guenter Roeck , Thierry Reding , MTD Maling List , Linux I2C , Miquel Raynal , linux-phy@lists.infradead.org, linux-spi , Jiri Slaby , "David S. Miller" , Khuong Dinh , Florian Fainelli , Matthias Schiffer , Kamal Dasu , Greg Kroah-Hartman , Lee Jones , Bartosz Golaszewski , Daniel Lezcano , Kishon Vijay Abraham I , bcm-kernel-feedback-list , "open list:SERIAL DRIVERS" , Jakub Kicinski , Zhang Rui , platform-driver-x86@vger.kernel.org, Linux PWM List , Robert Richter , Saravanan Sekar , Corey Minyard , Linux PM list , Liam Girdwood , Mauro Carvalho Chehab , John Garry , Peter Korsgaard , William Breathitt Gray , Mark Gross , Hans de Goede , Alex Williamson , Mark Brown , Borislav Petkov , Takashi Iwai , Matthias Brugger , openipmi-developer@lists.sourceforge.net, Andy Shevchenko , Benson Leung , Pengutronix Kernel Team , Linux ARM , linux-edac@vger.kernel.org, Tony Luck , Richard Weinberger , Mun Yew Tham , Eric Auger , netdev , "open list:GPIO SUBSYSTEM" , Cornelia Huck , Linux MMC List , Joakim Zhang , Linux Kernel Mailing List , Linux-Renesas , Sergey Shtylyov , Vinod Koul , James Morse , Zha Qipeng , Sebastian Reichel , Niklas =?utf-8?Q?S=C3=B6derlund?= , linux-mediatek@lists.infradead.org, Brian Norris , Yoshihiro Shimoda Subject: Re: [PATCH 1/2] platform: make platform_get_irq_optional() optional Message-ID: <20220118120806.pbjsat4ulg3vnhsh@pengutronix.de> References: <20220117092444.opoedfcf5k5u6otq@pengutronix.de> <20220117114923.d5vajgitxneec7j7@pengutronix.de> <20220117170609.yxaamvqdkivs56ju@pengutronix.de> <20220118090913.pjumkq4zf4iqtlha@pengutronix.de> MIME-Version: 1.0 In-Reply-To: X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-mediatek@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220118_040946_488492_90349105 X-CRM114-Status: GOOD ( 33.94 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5180779702241489005==" Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org --===============5180779702241489005== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2svqigojwuu4sr3n" Content-Disposition: inline --2svqigojwuu4sr3n Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Geert, On Tue, Jan 18, 2022 at 10:37:25AM +0100, Geert Uytterhoeven wrote: > On Tue, Jan 18, 2022 at 10:09 AM Uwe Kleine-K=F6nig > wrote: > > For the (clk|gpiod|regulator)_get_optional() you don't have to check > > against the magic not-found value (so no implementation detail magic > > leaks into the caller code) and just pass it to the next API function. > > (And my expectation would be that if you chose to represent not-found by > > (void *)66 instead of NULL, you won't have to adapt any user, just the > > framework internal checks. This is a good thing!) >=20 > Ah, there is the wrong assumption: drivers sometimes do need to know > if the resource was found, and thus do need to know about (void *)66, > -ENODEV, or -ENXIO. I already gave examples for IRQ and clk before. > I can imagine these exist for gpiod and regulator, too, as soon as > you go beyond the trivial "enable" and "disable" use-cases. My premise is that every user who has to check for "not found" explicitly should not use (clk|gpiod)_get_optional() but (clk|gpiod)_get() and do proper (and explicit) error handling for -ENODEV. (clk|gpiod)_get_optional() is only for these trivial use-cases. > And 0/NULL vs. > 0 is the natural check here: missing, but not > an error. For me it it 100% irrelevant if "not found" is an error for the query function or not. I just have to be able to check for "not found" and react accordingly. And adding a function def platform_get_irq_opional(): ret =3D platform_get_irq() if ret =3D=3D -ENXIO: return 0 return ret it's not a useful addition to the API if I cannot use 0 as a dummy because it doesn't simplify the caller enough to justify the additional function. The only thing I need to be able is to distinguish the cases "there is an irq", "there is no irq" and anything else is "there is a problem I cannot handle and so forward it to my caller". The semantic of platform_get_irq() is able to satisfy this requirement[1], so why introduce platform_get_irq_opional() for the small advantage that I can check for not-found using if (!irq) instead of if (irq !=3D -ENXIO) ? The semantic of platform_get_irq() is easier ("Either a usable non-negative irq number or a negative error number") compared to platform_get_irq_optional() ("Either a usable positive irq number or a negative error number or 0 meaning not found"). Usage of platform_get_irq() isn't harder or more expensive (neither for a human reader nor for a maching running the resulting compiled code). For a human reader if (irq !=3D -ENXIO) is even easier to understand because for if (!irq) they have to check where the value comes from, see it's platform_get_irq_optional() and understand that 0 means not-found. This function just adds overhead because as a irq framework user I have to understand another function. For me the added benefit is too small to justify the additional function. And you break out-of-tree drivers. These are all no major counter arguments, but as the advantage isn't major either, they still matter. Best regards Uwe [1] the only annoying thing is the error message. --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --2svqigojwuu4sr3n Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAmHmraMACgkQwfwUeK3K 7Ak1qwf6Am8XN0nqXfS0pbngp7EaV4pL4oNS8RQxKSvsObY254xYZ+ARuc9D/qcI /twFVp0MmVPlJHmpEM8KLdVakfXpJlaJRkoNiXFxGO6FJGbPNXIQvl33fM4L9u3c k8jyDoz2mdmZdpc6JSLgLroVyQXOl/WygxRbgqO0WCHu762nPfCuaaKUb2yzQ0I1 m+08eRtqVh8WqbbOHrpIhcpfPYzkCeRiGeaqGkO5YwvqeH6kv6eudm8RkAfo6DE9 IwzIaWANKnEqD3UzsSUPdPTmMPfqWML7RJPs6sZCdumiS+Ox36ZGrc7Ewn2ffU/V Q83qyxKFK+RfjJQmmPycReC6KM89bw== =RHyZ -----END PGP SIGNATURE----- --2svqigojwuu4sr3n-- --===============5180779702241489005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek --===============5180779702241489005==-- 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5F97FC433F5 for ; Tue, 18 Jan 2022 12:09:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=dS2dIsT3ckIve+feAS7VvjfqwRQpvqHcEY+PD/qm7oI=; b=wazO7bBnbsQ9oi2tT6RG4KPHUF dO9R6C1lH3OOfG9lNmvyX4es5AAeJIpEm9CyzJ/ADpgjD2bhGTSPBLY5EGfI/9//Afyh+5taq4iqQ RNeA+iBQwjodjGzDTdgCdE3yq9QpmOpiQkRdIPlSrxciCtg7ZPi17/VuSNPudzq+2ta495rqPURQE 68PDuFs2X62cb3yR6UuJi9gdNpTT8fx/Xc1XI0dLv+v4JHt+Uuo9/jXycyr/aYfDMx5Kcme6kzlC+ 0o26Ou0LSJBAY9Az1YR+5jH9+JctCVcynQV2Gbgl7PBtSGgB5W6yk+dktC2lcwtHRkqB3xDeD9XG3 e2yyok/A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9nJG-001S35-RH; Tue, 18 Jan 2022 12:09:58 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9nJ1-001S1U-5t for linux-phy@lists.infradead.org; Tue, 18 Jan 2022 12:09:45 +0000 Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9nHg-0001Dm-Ou; Tue, 18 Jan 2022 13:08:20 +0100 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n9nHT-00AzwP-Do; Tue, 18 Jan 2022 13:08:06 +0100 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1n9nHS-0004EX-Dv; Tue, 18 Jan 2022 13:08:06 +0100 Date: Tue, 18 Jan 2022 13:08:06 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Geert Uytterhoeven Cc: Andrew Lunn , Ulf Hansson , Vignesh Raghavendra , KVM list , "Rafael J. Wysocki" , linux-iio@vger.kernel.org, Linus Walleij , Amit Kucheria , ALSA Development Mailing List , Jaroslav Kysela , Guenter Roeck , Thierry Reding , MTD Maling List , Linux I2C , Miquel Raynal , linux-phy@lists.infradead.org, linux-spi , Jiri Slaby , "David S. Miller" , Khuong Dinh , Florian Fainelli , Matthias Schiffer , Kamal Dasu , Greg Kroah-Hartman , Lee Jones , Bartosz Golaszewski , Daniel Lezcano , Kishon Vijay Abraham I , bcm-kernel-feedback-list , "open list:SERIAL DRIVERS" , Jakub Kicinski , Zhang Rui , platform-driver-x86@vger.kernel.org, Linux PWM List , Robert Richter , Saravanan Sekar , Corey Minyard , Linux PM list , Liam Girdwood , Mauro Carvalho Chehab , John Garry , Peter Korsgaard , William Breathitt Gray , Mark Gross , Hans de Goede , Alex Williamson , Mark Brown , Borislav Petkov , Takashi Iwai , Matthias Brugger , openipmi-developer@lists.sourceforge.net, Andy Shevchenko , Benson Leung , Pengutronix Kernel Team , Linux ARM , linux-edac@vger.kernel.org, Tony Luck , Richard Weinberger , Mun Yew Tham , Eric Auger , netdev , "open list:GPIO SUBSYSTEM" , Cornelia Huck , Linux MMC List , Joakim Zhang , Linux Kernel Mailing List , Linux-Renesas , Sergey Shtylyov , Vinod Koul , James Morse , Zha Qipeng , Sebastian Reichel , Niklas =?utf-8?Q?S=C3=B6derlund?= , linux-mediatek@lists.infradead.org, Brian Norris , Yoshihiro Shimoda Subject: Re: [PATCH 1/2] platform: make platform_get_irq_optional() optional Message-ID: <20220118120806.pbjsat4ulg3vnhsh@pengutronix.de> References: <20220117092444.opoedfcf5k5u6otq@pengutronix.de> <20220117114923.d5vajgitxneec7j7@pengutronix.de> <20220117170609.yxaamvqdkivs56ju@pengutronix.de> <20220118090913.pjumkq4zf4iqtlha@pengutronix.de> MIME-Version: 1.0 In-Reply-To: X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-phy@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220118_040943_436801_6BF4CF19 X-CRM114-Status: GOOD ( 33.74 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8175193908298840988==" Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org --===============8175193908298840988== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2svqigojwuu4sr3n" Content-Disposition: inline --2svqigojwuu4sr3n Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Geert, On Tue, Jan 18, 2022 at 10:37:25AM +0100, Geert Uytterhoeven wrote: > On Tue, Jan 18, 2022 at 10:09 AM Uwe Kleine-K=F6nig > wrote: > > For the (clk|gpiod|regulator)_get_optional() you don't have to check > > against the magic not-found value (so no implementation detail magic > > leaks into the caller code) and just pass it to the next API function. > > (And my expectation would be that if you chose to represent not-found by > > (void *)66 instead of NULL, you won't have to adapt any user, just the > > framework internal checks. This is a good thing!) >=20 > Ah, there is the wrong assumption: drivers sometimes do need to know > if the resource was found, and thus do need to know about (void *)66, > -ENODEV, or -ENXIO. I already gave examples for IRQ and clk before. > I can imagine these exist for gpiod and regulator, too, as soon as > you go beyond the trivial "enable" and "disable" use-cases. My premise is that every user who has to check for "not found" explicitly should not use (clk|gpiod)_get_optional() but (clk|gpiod)_get() and do proper (and explicit) error handling for -ENODEV. (clk|gpiod)_get_optional() is only for these trivial use-cases. > And 0/NULL vs. > 0 is the natural check here: missing, but not > an error. For me it it 100% irrelevant if "not found" is an error for the query function or not. I just have to be able to check for "not found" and react accordingly. And adding a function def platform_get_irq_opional(): ret =3D platform_get_irq() if ret =3D=3D -ENXIO: return 0 return ret it's not a useful addition to the API if I cannot use 0 as a dummy because it doesn't simplify the caller enough to justify the additional function. The only thing I need to be able is to distinguish the cases "there is an irq", "there is no irq" and anything else is "there is a problem I cannot handle and so forward it to my caller". The semantic of platform_get_irq() is able to satisfy this requirement[1], so why introduce platform_get_irq_opional() for the small advantage that I can check for not-found using if (!irq) instead of if (irq !=3D -ENXIO) ? The semantic of platform_get_irq() is easier ("Either a usable non-negative irq number or a negative error number") compared to platform_get_irq_optional() ("Either a usable positive irq number or a negative error number or 0 meaning not found"). Usage of platform_get_irq() isn't harder or more expensive (neither for a human reader nor for a maching running the resulting compiled code). For a human reader if (irq !=3D -ENXIO) is even easier to understand because for if (!irq) they have to check where the value comes from, see it's platform_get_irq_optional() and understand that 0 means not-found. This function just adds overhead because as a irq framework user I have to understand another function. For me the added benefit is too small to justify the additional function. And you break out-of-tree drivers. These are all no major counter arguments, but as the advantage isn't major either, they still matter. Best regards Uwe [1] the only annoying thing is the error message. --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --2svqigojwuu4sr3n Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAmHmraMACgkQwfwUeK3K 7Ak1qwf6Am8XN0nqXfS0pbngp7EaV4pL4oNS8RQxKSvsObY254xYZ+ARuc9D/qcI /twFVp0MmVPlJHmpEM8KLdVakfXpJlaJRkoNiXFxGO6FJGbPNXIQvl33fM4L9u3c k8jyDoz2mdmZdpc6JSLgLroVyQXOl/WygxRbgqO0WCHu762nPfCuaaKUb2yzQ0I1 m+08eRtqVh8WqbbOHrpIhcpfPYzkCeRiGeaqGkO5YwvqeH6kv6eudm8RkAfo6DE9 IwzIaWANKnEqD3UzsSUPdPTmMPfqWML7RJPs6sZCdumiS+Ox36ZGrc7Ewn2ffU/V Q83qyxKFK+RfjJQmmPycReC6KM89bw== =RHyZ -----END PGP SIGNATURE----- --2svqigojwuu4sr3n-- --===============8175193908298840988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy --===============8175193908298840988==-- 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 alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8B6A7C433F5 for ; Thu, 20 Jan 2022 07:09:47 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id E2BB02FFC; Thu, 20 Jan 2022 08:08:55 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz E2BB02FFC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1642662585; bh=IqZK5eaKhd4Z1Pr7ThpWTLe3vjhfsHO+95oqDqUBCfU=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=l+aRPxifWU1wuJEE3qlpCiMGMByX3Kl6p1nv0gwroimLTWwaZlqOiOstV6rfk1/XQ V75e+2eheUMbbawzSBFOS9lxasEdySDrPwnYt1As4E9Hv8fZRerRCqSGree+UbTAsG EV4f21HD8kCiPW+8kDnwtRB5cmAFM0bRI2hH8Ph8= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 64C6AF8057B; Thu, 20 Jan 2022 08:03:48 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 60FEDF8023B; Tue, 18 Jan 2022 13:08:31 +0100 (CET) Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 5382DF800CE for ; Tue, 18 Jan 2022 13:08:23 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 5382DF800CE Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9nHg-0001Dm-Ou; Tue, 18 Jan 2022 13:08:20 +0100 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n9nHT-00AzwP-Do; Tue, 18 Jan 2022 13:08:06 +0100 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1n9nHS-0004EX-Dv; Tue, 18 Jan 2022 13:08:06 +0100 Date: Tue, 18 Jan 2022 13:08:06 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Geert Uytterhoeven Subject: Re: [PATCH 1/2] platform: make platform_get_irq_optional() optional Message-ID: <20220118120806.pbjsat4ulg3vnhsh@pengutronix.de> References: <20220117092444.opoedfcf5k5u6otq@pengutronix.de> <20220117114923.d5vajgitxneec7j7@pengutronix.de> <20220117170609.yxaamvqdkivs56ju@pengutronix.de> <20220118090913.pjumkq4zf4iqtlha@pengutronix.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2svqigojwuu4sr3n" Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: alsa-devel@alsa-project.org X-Mailman-Approved-At: Thu, 20 Jan 2022 08:03:35 +0100 Cc: Andrew Lunn , Ulf Hansson , Vignesh Raghavendra , KVM list , "Rafael J. Wysocki" , linux-iio@vger.kernel.org, Linus Walleij , Amit Kucheria , ALSA Development Mailing List , Andy Shevchenko , Guenter Roeck , Thierry Reding , MTD Maling List , Linux I2C , Miquel Raynal , linux-phy@lists.infradead.org, netdev , Jiri Slaby , openipmi-developer@lists.sourceforge.net, Khuong Dinh , Florian Fainelli , Matthias Schiffer , Joakim Zhang , Kamal Dasu , Lee Jones , Bartosz Golaszewski , Daniel Lezcano , Kishon Vijay Abraham I , bcm-kernel-feedback-list , "open list:SERIAL DRIVERS" , Yoshihiro Shimoda , Jakub Kicinski , Zhang Rui , Linux PWM List , Robert Richter , Saravanan Sekar , Corey Minyard , Linux PM list , Linux Kernel Mailing List , Mauro Carvalho Chehab , John Garry , Peter Korsgaard , William Breathitt Gray , Mark Gross , Hans de Goede , Alex Williamson , Mark Brown , Borislav Petkov , Sebastian Reichel , Matthias Brugger , Takashi Iwai , platform-driver-x86@vger.kernel.org, Benson Leung , Linux ARM , linux-edac@vger.kernel.org, Tony Luck , Mun Yew Tham , Eric Auger , Greg Kroah-Hartman , "open list:GPIO SUBSYSTEM" , Cornelia Huck , Linux MMC List , Liam Girdwood , linux-spi , Linux-Renesas , Sergey Shtylyov , Vinod Koul , James Morse , Zha Qipeng , Pengutronix Kernel Team , Richard Weinberger , Niklas =?utf-8?Q?S=C3=B6derlund?= , linux-mediatek@lists.infradead.org, Brian Norris , "David S. Miller" X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" --2svqigojwuu4sr3n Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Geert, On Tue, Jan 18, 2022 at 10:37:25AM +0100, Geert Uytterhoeven wrote: > On Tue, Jan 18, 2022 at 10:09 AM Uwe Kleine-K=F6nig > wrote: > > For the (clk|gpiod|regulator)_get_optional() you don't have to check > > against the magic not-found value (so no implementation detail magic > > leaks into the caller code) and just pass it to the next API function. > > (And my expectation would be that if you chose to represent not-found by > > (void *)66 instead of NULL, you won't have to adapt any user, just the > > framework internal checks. This is a good thing!) >=20 > Ah, there is the wrong assumption: drivers sometimes do need to know > if the resource was found, and thus do need to know about (void *)66, > -ENODEV, or -ENXIO. I already gave examples for IRQ and clk before. > I can imagine these exist for gpiod and regulator, too, as soon as > you go beyond the trivial "enable" and "disable" use-cases. My premise is that every user who has to check for "not found" explicitly should not use (clk|gpiod)_get_optional() but (clk|gpiod)_get() and do proper (and explicit) error handling for -ENODEV. (clk|gpiod)_get_optional() is only for these trivial use-cases. > And 0/NULL vs. > 0 is the natural check here: missing, but not > an error. For me it it 100% irrelevant if "not found" is an error for the query function or not. I just have to be able to check for "not found" and react accordingly. And adding a function def platform_get_irq_opional(): ret =3D platform_get_irq() if ret =3D=3D -ENXIO: return 0 return ret it's not a useful addition to the API if I cannot use 0 as a dummy because it doesn't simplify the caller enough to justify the additional function. The only thing I need to be able is to distinguish the cases "there is an irq", "there is no irq" and anything else is "there is a problem I cannot handle and so forward it to my caller". The semantic of platform_get_irq() is able to satisfy this requirement[1], so why introduce platform_get_irq_opional() for the small advantage that I can check for not-found using if (!irq) instead of if (irq !=3D -ENXIO) ? The semantic of platform_get_irq() is easier ("Either a usable non-negative irq number or a negative error number") compared to platform_get_irq_optional() ("Either a usable positive irq number or a negative error number or 0 meaning not found"). Usage of platform_get_irq() isn't harder or more expensive (neither for a human reader nor for a maching running the resulting compiled code). For a human reader if (irq !=3D -ENXIO) is even easier to understand because for if (!irq) they have to check where the value comes from, see it's platform_get_irq_optional() and understand that 0 means not-found. This function just adds overhead because as a irq framework user I have to understand another function. For me the added benefit is too small to justify the additional function. And you break out-of-tree drivers. These are all no major counter arguments, but as the advantage isn't major either, they still matter. Best regards Uwe [1] the only annoying thing is the error message. --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --2svqigojwuu4sr3n Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAmHmraMACgkQwfwUeK3K 7Ak1qwf6Am8XN0nqXfS0pbngp7EaV4pL4oNS8RQxKSvsObY254xYZ+ARuc9D/qcI /twFVp0MmVPlJHmpEM8KLdVakfXpJlaJRkoNiXFxGO6FJGbPNXIQvl33fM4L9u3c k8jyDoz2mdmZdpc6JSLgLroVyQXOl/WygxRbgqO0WCHu762nPfCuaaKUb2yzQ0I1 m+08eRtqVh8WqbbOHrpIhcpfPYzkCeRiGeaqGkO5YwvqeH6kv6eudm8RkAfo6DE9 IwzIaWANKnEqD3UzsSUPdPTmMPfqWML7RJPs6sZCdumiS+Ox36ZGrc7Ewn2ffU/V Q83qyxKFK+RfjJQmmPycReC6KM89bw== =RHyZ -----END PGP SIGNATURE----- --2svqigojwuu4sr3n--