Date:   Sat, 15 Jan 2022 14:55:50 +0100
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Sergey Shtylyov <s.shtylyov@....ru>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Mark Brown <broonie@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Vignesh Raghavendra <vigneshr@...com>,
        KVM list <kvm@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>, linux-iio@...r.kernel.org,
        Linus Walleij <linus.walleij@...aro.org>,
        Amit Kucheria <amitk@...nel.org>,
        ALSA Development Mailing List <alsa-devel@...a-project.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Guenter Roeck <groeck@...omium.org>,
        Thierry Reding <thierry.reding@...il.com>,
        MTD Maling List <linux-mtd@...ts.infradead.org>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        linux-phy@...ts.infradead.org, netdev@...r.kernel.org,
        linux-spi <linux-spi@...r.kernel.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Khuong Dinh <khuong@...amperecomputing.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        Kamal Dasu <kdasu.kdev@...il.com>,
        Lee Jones <lee.jones@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Kishon Vijay Abraham I <kishon@...com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
        Zhang Rui <rui.zhang@...el.com>,
        platform-driver-x86@...r.kernel.org,
        Linux PWM List <linux-pwm@...r.kernel.org>,
        Robert Richter <rric@...nel.org>,
        Saravanan Sekar <sravanhome@...il.com>,
        Corey Minyard <minyard@....org>,
        Linux PM list <linux-pm@...r.kernel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        John Garry <john.garry@...wei.com>,
        Takashi Iwai <tiwai@...e.com>,
        Peter Korsgaard <peter@...sgaard.com>,
        William Breathitt Gray <vilhelm.gray@...il.com>,
        Mark Gross <markgross@...nel.org>,
        Hans de Goede <hdegoede@...hat.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Jakub Kicinski <kuba@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        openipmi-developer@...ts.sourceforge.net,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Benson Leung <bleung@...omium.org>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-edac@...r.kernel.org, Tony Luck <tony.luck@...el.com>,
        Richard Weinberger <richard@....at>,
        Mun Yew Tham <mun.yew.tham@...el.com>,
        Eric Auger <eric.auger@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Cornelia Huck <cohuck@...hat.com>,
        Linux MMC List <linux-mmc@...r.kernel.org>,
        Joakim Zhang <qiangqing.zhang@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Vinod Koul <vkoul@...nel.org>,
        James Morse <james.morse@....com>,
        Zha Qipeng <qipeng.zha@...el.com>,
        Sebastian Reichel <sre@...nel.org>,
        Niklas Söderlund <niklas.soderlund@...natech.se>,
        linux-mediatek@...ts.infradead.org,
        Brian Norris <computersforpeace@...il.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] driver core: platform: Rename
 platform_get_irq_optional() to platform_get_irq_silent()

On Fri, Jan 14, 2022 at 08:55:07PM +0300, Sergey Shtylyov wrote:
> On 1/14/22 12:42 AM, Florian Fainelli wrote:
> 
> >> The subsystems regulator, clk and gpio have the concept of a dummy
> >> resource. For regulator, clk and gpio there is a semantic difference
> >> between the regular _get() function and the _get_optional() variant.
> >> (One might return the dummy resource, the other won't. Unfortunately
> >> which one implements which isn't the same for these three.) The
> >> difference between platform_get_irq() and platform_get_irq_optional() is
> >> only that the former might emit an error message and the later won't.
> >>
> >> To prevent people's expectations that there is a semantic difference
> >> between these too, rename platform_get_irq_optional() to
> >> platform_get_irq_silent() to make the actual difference more obvious.
> >>
> >> The #define for the old name can and should be removed once all patches
> >> currently in flux still relying on platform_get_irq_optional() are
> >> fixed.
> >>
> >> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
> [...]
> >>>> I think at least c) is easy to resolve because
> >>>> platform_get_irq_optional() isn't that old yet and mechanically
> >>>> replacing it by platform_get_irq_silent() should be easy and safe.
> >>>> And this is orthogonal to the discussion if -ENOXIO is a sensible return
> >>>> value and if it's as easy as it could be to work with errors on irq
> >>>> lookups.
> >>>
> >>> It'd certainly be good to name anything that doesn't correspond to one
> >>> of the existing semantics for the API (!) something different rather
> >>> than adding yet another potentially overloaded meaning.
> >>
> >> It seems we're (at least) three who agree about this. Here is a patch
> >> fixing the name.
> > 
> > From an API naming perspective this does not make much sense anymore with the name chosen,
> > it is understood that whent he function is called platform_get_irq_optional(), optional applies
> > to the IRQ. An optional IRQ is something people can reason about because it makes sense.
> 
>    Right! :-)
> 
> > What is a a "silent" IRQ however? It does not apply to the object it is trying to fetch to
> > anymore, but to the message that may not be printed in case the resource failed to be obtained,
> > because said resource is optional. Woah, that's quite a stretch.
> 
>    Right again! :-)

So you oppose to the name chosen, but not the renaming as such. I
already asked Florian if he has a better name, do you have a
constructive suggestion? What about platform_silently_get_irq? Or
platform_get_irq_silently?

Do you agree that it's unfortunate that platform_get_irq_optional() has a
different usage convention than clk_get_optional() and
gpiod_get_optional()?

Do you agree that the difference between platform_get_irq_optional() and
platform_get_irq() is only that one of them issues an error message and
the other doesn't?

Currently the return values of platform_get_irq_optional() and
platform_get_irq() are identical. Do you agree that any change to clean
up the return value convention of platform_get_irq_optional() also
would be sensible for platform_get_irq()?

Do you agree that changing the way how return values of
platform_get_irq_optional() have to be evaluated without adapting
platform_get_irq() in the same way, artifially breaks the releation
between these two functions?

> > Following the discussion and original 2 patches set from Sergey, it is not entirely clear to me
> > anymore what is it that we are trying to fix.
> 
>    Andy and me tried to fix the platform_get_irq[_byname]_optional() value, corresponding to
> a missing (optional) IRQ resource from -ENXIO to 0, in order to keep the callers error code
> agnostic. This change completely aligns e.g. platform_get_irq_optional() with clk_get_optional()
> and gpiod_get_optional()...

Did you read and understand my objection? Yes, in the not found case the
return value is a 32-bit or 64-bit long zero value (0 or NULL) for these
functions. But for irqs you cannot treat that as an irq number. For clks
this works, and this is the fact that justifies the "optional" in the
name and that simplifies further handling without having to check if the
value returned by clk_get_optional corresponds to the dummy clk or a
real one. Just returning 0 for not-found doesn't justify "optional" in
the name. Or do you think kmalloc should better be called
kmalloc_optional because it returns NULL if there is no more memory
available?

The only thing you accomplish with returning 0 instead of -ENXIO is that
the check for this value in the callers has to be adapted. But as you
cannot handle 0 and a "normal" irq in the same way (i.e. pass it to
request_irq) 

In my eyes error code agnostic isn't a sensible goal. If you ask for a
resource and it's not there and your driver can cope and this cannot be
done by just treating the returned value as a valid resource, making it
explicit that the error code for "not found" is handled is a good thing.
In my opinion it's not a good enough reason to change a function's
return conventions just that I can handle one of the various results
using

	if (ret == 0)

instead of

	if (ret == -ENXIO)

Also there is no justification to change the value for "not found" to
zero. The next developer might be annoyed by having to check for
-EPROBE_DEFER and wants to introduce a special function that behaves
like platform_get_irq, just returns 0 when platform_get_irq returns
-ENOENT.

>    Unforunately, we can't "fix" request_irq() and company to treat 0 as missing IRQ -- they have
> to keep the ability to get called from the arch/ code (that doesn't use platform_get_irq(), etc.

Note that even if request_irq would be a noop for 0, the biggest part of
the drivers wouldn't be done with request_irq(0, ...) because in the
absense of an irq something has to be done about it.

Oh my, I failed to not continue this discussion really badly. But I
really cannot stand people arguing for wrong things and ignoring my
reasoning completely. In case you feel the same way: I agree that -ENXIO
is the wrong value for not-found. But to change this wrong behaviour to
another wrong behaviour isn't an improvement.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists