Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5335487pxb; Wed, 19 Jan 2022 16:23:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJzktvf4nICtC63XF7J6OzLjXLnFHBHJ2mx3MlcmSMWD/4r/ezSeXZtubzqiy89oSnpn2HnE X-Received: by 2002:a17:90a:e7c4:: with SMTP id kb4mr7345032pjb.144.1642638233792; Wed, 19 Jan 2022 16:23:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642638233; cv=none; d=google.com; s=arc-20160816; b=nJ3FPkTZvOvWRN6NXaClHqX8OOVQarxN9KAgX5962I3EGn7plJtADfTjFpcxuLQkPO +6gk2DAeZ+EkJr1yehI134KLzmf0pLRCad+Cy+6Tl9a8sm1sSzp+qglDoTHykVghd9y6 Wq3XO5CcoTU9r6o1WW8R28RZqFxV5FuE0YCiCGQwSCkO00m/PljgEDk9DlNOUuWV5jC4 F433a/i2dneN074PULSUlQp9jvdma4TCMk/hX0Tx0ICPLT1aKpyaI+Gjcc3j8h8G3/ZY R512Q0nT9JRU6hfOK9bsdsSkAGtqCrcOUBcDOSnI8VMJ6Ks5vJ9FuiN57EUWE7ZpilJ8 pkKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=HgJTDcOuNrlsJaIDt2f+9e7RjfZgDJWS1+yjGbvW9HY=; b=sni6/x5faEsrddXp0sYS887zK0M9jS56nvhDtCkM9BL0HVNSm4D3+tuF5x9knlR2Ey Xk3PDQb6p/mui+8HMz1QOn6725rOyi3tlRoslcGKCgl3KDpmUWwvA2fwuzLGlsq6Nvhk BLtWQ6cwYzMKTKOWRm4/cVs3f7hhOPPsDq6gFQqj8/mxlK2nylXPeKRi6bYyHPHTJwiw 34Jmk2dTVNuriNQcyoSx+OpDAYQK7KYMJ115wuzg3ylbbp7nViWlW2wMlQxr8rRnzKm7 TSogZNyysiVW290ZCTKK/MWKA7lrwX3cNgJqQ5XVFv4e6Lp1VwpXX3aZiIahB+xsHadE js4A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y32si1558094pgk.136.2022.01.19.16.23.41; Wed, 19 Jan 2022 16:23:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345246AbiARJKh (ORCPT + 99 others); Tue, 18 Jan 2022 04:10:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240529AbiARJKf (ORCPT ); Tue, 18 Jan 2022 04:10:35 -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 BD5E3C061401 for ; Tue, 18 Jan 2022 01:10:34 -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 1n9kUa-0004vq-CT; Tue, 18 Jan 2022 10:09:28 +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 1n9kUO-00AyFG-5e; Tue, 18 Jan 2022 10:09:15 +0100 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1n9kUN-0002sb-15; Tue, 18 Jan 2022 10:09:15 +0100 Date: Tue, 18 Jan 2022 10:09:13 +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 , Andy Shevchenko , Jaroslav Kysela , 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" , 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 , Eric Auger , Matthias Brugger , Takashi Iwai , platform-driver-x86@vger.kernel.org, Benson Leung , Linux ARM , linux-edac@vger.kernel.org, Tony Luck , Mun Yew Tham , "open list:GPIO SUBSYSTEM" , Greg Kroah-Hartman , Yoshihiro Shimoda , 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" Subject: Re: [PATCH 1/2] platform: make platform_get_irq_optional() optional Message-ID: <20220118090913.pjumkq4zf4iqtlha@pengutronix.de> References: <61b80939-357d-14f5-df99-b8d102a4e1a1@omp.ru> <20220114202226.ugzklxv4wzr6egwj@pengutronix.de> <20220117092444.opoedfcf5k5u6otq@pengutronix.de> <20220117114923.d5vajgitxneec7j7@pengutronix.de> <20220117170609.yxaamvqdkivs56ju@pengutronix.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bm2t43tlpbmr2x5i" 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-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --bm2t43tlpbmr2x5i Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Geert, On Tue, Jan 18, 2022 at 09:25:01AM +0100, Geert Uytterhoeven wrote: > On Mon, Jan 17, 2022 at 6:06 PM Uwe Kleine-K=F6nig > wrote: > > On Mon, Jan 17, 2022 at 02:08:19PM +0100, Geert Uytterhoeven wrote: > > > On Mon, Jan 17, 2022 at 12:49 PM Uwe Kleine-K=F6nig > > > wrote: > > > > > So there are three reasons: because the absence of an optional IRQ > > > > > is not an error, and thus that should not cause (a) an error code > > > > > to be returned, and (b) an error message to be printed, and (c) > > > > > because it can simplify the logic in device drivers. > > > > > > > > I don't agree to (a). If the value signaling not-found is -ENXIO or= 0 > > > > (or -ENODEV) doesn't matter much. I wouldn't deviate from the return > > > > code semantics of platform_get_irq() just for having to check again= st 0 > > > > instead of -ENXIO. Zero is then just another magic value. > > > > > > Zero is a natural magic value (also for pointers). > > > Errors are always negative. > > > Positive values are cookies (or pointers) associated with success. > > > > Yeah, the issue where we don't agree is if "not-found" is special enough > > to deserve the natural magic value. For me -ENXIO is magic enough to > > handle the absence of an irq line. I consider it even the better magic > > value. >=20 > It differs from other subsystems (clk, gpio, reset), which do return > zero on not found. IMHO it doesn't matter at all that the return value is zero, relevant is the semantic of the returned value. For clk, gpio, reset and regulator NULL is a usable dummy, for irqs it's not. So what you do with the value returned by platform_get_irq_whatever() is: you compare it with the (magic?) not-found value, and if it matches, you enter a suitable if-block. 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!) > What's the point in having *_optional() APIs if they just return the > same values as the non-optional ones? The upside is that functions with a similar name have similar semantics. But I agree, having platform_get_irq_optional() with the same return value for not-found is bad. Changing the return semantic is only one way to cope with that, renaming such the actual semantic difference is obvious from the function name is another (IMHO better one).=20 Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --bm2t43tlpbmr2x5i Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAmHmg7YACgkQwfwUeK3K 7Amhogf/dAjmJCBciWgz5NV3TfnJ8zBdFusKYKkLMRX6hggDS981lVDd/+0J/CXt OTZ/mg6pMVEdM4ZgmE7oLUUXSj26rQAXG0Tn0LElJNjNi2w6+jApwXacf1NIrjdY xuNSbiN94DwWHsG5fgK6ij9XQ1Y0VM23PBPhfBFJUBh2uwTWa/N2akSLPpO4xpcI qRk9h8QiaRxs+68qmLL5RA1wkp7oyAigMEUcgBr3qUFhTdSGAENP2ZWfgy1ONoFr ajWgfvPfJ0DAwLiGwyrLebtzFgmd1NwSqNEVsBLdDSkGDq1ysDF6kccVIYnJmWdD ioq82+vTregbKeZC6dz5wBLZ/E1KSA== =u/8Z -----END PGP SIGNATURE----- --bm2t43tlpbmr2x5i--