netdev - Re: [PATCH v4 4/7] pinctrl: wpcm450: elax return value check for IRQ get

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZGUI4J27h69ed005@smile.fi.intel.com>
Date: Wed, 17 May 2023 20:03:28 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Jonathan Neuschäfer <j.neuschaefer@....net>
Cc: Matti Vaittinen <mazziesaccount@...il.com>,
	Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
	Daniel Scally <djrscally@...il.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Michael Hennerich <Michael.Hennerich@...log.com>,
	Jonathan Cameron <jic23@...nel.org>,
	Andreas Klinger <ak@...klinger.de>, Marcin Wojtas <mw@...ihalf.com>,
	Russell King <linux@...linux.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Paul Cercueil <paul@...pouillou.net>, Wolfram Sang <wsa@...nel.org>,
	Akhil R <akhilrajeev@...dia.com>, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
	netdev@...r.kernel.org, openbmc@...ts.ozlabs.org,
	linux-gpio@...r.kernel.org, linux-mips@...r.kernel.org
Subject: Re: [PATCH v4 4/7] pinctrl: wpcm450: elax return value check for IRQ
 get

On Tue, May 16, 2023 at 06:32:09PM +0200, Jonathan Neuschäfer wrote:
> On Tue, May 16, 2023 at 10:13:14AM +0300, Matti Vaittinen wrote:

> > The special handling in this driver was added when fixing a problem
> > where returning zero from fwnode_irq_get[_byname]() was treated as
> > succes yielding zero being used as a valid IRQ by the driver.
> > f4a31facfa80 ("pinctrl: wpcm450: Correct the fwnode_irq_get() return value check")
> > The commit message does not mention if choosing not to abort the probe
> > on device-tree mapping failure (as is done on other errors) was chosen
> > because: a) Abort would have broken some existing setup. b) Because skipping
> > an IRQ on failure is "the right thing to do", or c) because it sounded like
> > a way to minimize risk of breaking something.
> > 
> > If the reason is a) - then I'd appreciate receiving some more
> > information and a suggestion how to proceed (if possible). If the reason
> > is b), then it might be best to just skip the IRQ instead of aborting
> > the probe for all errors on IRQ getting. Finally, in case of c), well,
> > by acking this change you will now accept the risk :)

>From my side it was c).

> > The first patch of the series changes the fwnode_irq_get() so this depends
> > on the first patch of the series and should not be applied alone.
> 
> Thanks for investigating this!
> 
> It's not a), because there are no existing setups that rely on broken
> IRQs connected to this pinctrl/GPIO controller.
> 
> I suspect b) or c), but I'll let Andy give a more definite answer.


-- 
With Best Regards,
Andy Shevchenko