No subject

platforms would make more sense.

I suspect that IRQF_VALID is something left behind from the times
before CONFIG_GENERIC_HARDIRQS. My not-so-qualified guess is that
IRQF_VALID was used to disallow request_irq() on irqs that lacked chip
backing.

Today IRQ_NOREQUEST seems to be used for chained interrupt handlers.
The check in request_threaded_irq() returns -EINVAL if IRQ_NOREQUEST
is set. This covers request_irq(), but setup_irq() is lacking a check.
Maybe this is done intentionally, or perhaps it's something I should
fix?

If the purpose with IRQF_VALID is to guard against
request_irq()/setup_irq() on irqs lacking chip backing, then good news
is that the CONFIG_GENERIC_HARDIRQ already has code to handle this for
us. Basically, the default in irq_desc_init makes use of &no_irq_chip.
And the __setup_irq() code is already checking against irqs mapped to
&no_irq_chip, those are disallowed with a -ENOSYS.

Is there any point in keeping IRQF_VALID on ARM, or shall I submit a
patch to clean things up?

Thanks,

/ magnus