On Wed, 2021-03-31 at 17:03 +0300, Andy Shevchenko wrote: > On Wed, Mar 31, 2021 at 4:36 PM Matthias Schiffer > <matthias.schiffer@xxxxxxxxxxxxxxx> wrote: > > > > On Wed, 2021-03-31 at 15:39 +0300, Andy Shevchenko wrote: > > > On Wed, Mar 31, 2021 at 3:37 PM Matthias Schiffer > > > <matthias.schiffer@xxxxxxxxxxxxxxx> wrote: > > > > On Wed, 2021-03-31 at 15:29 +0300, Andy Shevchenko wrote: > > ... > > > > > I don't understand which part of the code is dead now. I assume the > > > > `return irq` case is still useful for unexpected errors, or things like > > > > EPROBE_DEFER? I'm not sure if EPROBE_DEFER is relevant for this driver, > > > > but just ignoring the error code completely doesn't seem right to me. > > > > > > platform_get_irq() AFAIK won't ever return such a code. > > > So, basically your conditional is always false. > > > > > > I would like to see the code path which makes my comment wrong. > > > > > > > EPROBE_DEFER appears a few times in platform_get_irq_optional() > > (drivers/base/platform.c), but it's possible that this is only relevant > > for OF-based platforms and not x86. > > Ah, okay, that's something I haven't paid attention to. > > So the root cause of the your case is platform_get_irq_optional|() > return code. I'm wondering why it can't return 0 instead of absent > IRQ? Perhaps you need to fix it instead of lurking into each caller. > Hi Andy, what's the plan here? "driver core: platform: Make platform_get_irq_optional() optional" had to be reverted because it broke existing users of platform_get_irq_optional(). I'm not convinced that a slightly more convenient API is worth going through the trouble of fixing them all - I know we don't care much about out-of-tree modules, but subtly changing the behaviour of such a function doesn't seem like a good idea to me even if we review all in-tree users. Should I just rebase my patches with the existing ENXIO handing (and fix up the other issues that were noted), or do you intend to give the platform_get_irq_optional() revamp another try? Kind regards, Matthias