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
