| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 13 Jan 2022 12:08:31 +0100
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: Mark Brown <broonie@...nel.org>
Cc: 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>,
Miquel Raynal <miquel.raynal@...tlin.com>,
linux-phy@...ts.infradead.org, Jiri Slaby <jirislaby@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Khuong Dinh <khuong@...amperecomputing.com>,
Florian Fainelli <f.fainelli@...il.com>,
Matthias Schiffer <matthias.schiffer@...tq-group.com>,
Kamal Dasu <kdasu.kdev@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
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>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
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>,
Sergey Shtylyov <s.shtylyov@....ru>,
Borislav Petkov <bp@...en8.de>,
Eric Auger <eric.auger@...hat.com>,
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>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
netdev@...r.kernel.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-spi <linux-spi@...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 1/2] platform: make platform_get_irq_optional() optional
On Wed, Jan 12, 2022 at 09:45:25PM +0000, Mark Brown wrote:
> On Wed, Jan 12, 2022 at 10:31:21PM +0100, Uwe Kleine-König wrote:
> > On Wed, Jan 12, 2022 at 11:27:02AM +0100, Geert Uytterhoeven wrote:
>
> (Do we really need *all* the CCs here?)
It's probably counteractive to finding an agreement because there are
too many opinions on that matter. But I didn't dare to strip it down,
too :-)
> > That convinces me, that platform_get_irq_optional() is a bad name. The
> > only difference to platform_get_irq is that it's silent. And returning
> > a dummy irq value (which would make it aligned with the other _optional
> > functions) isn't possible.
>
> There is regulator_get_optional() which is I believe the earliest of
> these APIs, it doesn't return a dummy either (and is silent too) - this
> is because regulator_get() does return a dummy since it's the vastly
> common case that regulators must be physically present and them not
> being found is due to there being an error in the system description.
> It's unfortunate that we've ended up with these two different senses for
> _optional(), people frequently get tripped up by it.
Yeah, I tripped over that one already, too. And according to my counting
this results in three different senses now :-\ :
a) regulator
regulator_get returns a dummy, regulator_get_optional returns ERR_PTR(-ENODEV)
b) clk + gpiod
..._get returns ERR_PTR(-ENODEV), ..._get_optional returns a dummy
c) platform_get_irq()
platform_get_irq_optional() is just a silent variant of
platform_get_irq(); the return values are identical.
This is all very unfortunate. In my eyes b) is the most sensible
sense, but the past showed that we don't agree here. (The most annoying
part of regulator_get is the warning that is emitted that regularily
makes customers ask what happens here and if this is fixable.)
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.
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