[<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
Powered by blists - more mailing lists