use of set_irq_chip_and_handler...() for chained handlers vs sparse IRQs

["Jan Beulich" <JBeulich@novell.com>]

Thomas,

looking (originally from a Xen perspective) at the use of non-platform
specific drivers that set chained IRQ handlers (drivers/mfd/ezx-pcap.c,
drivers/gpio/langwell_gpio.c, and drivers/gpio/timbgpio.c are the ones
that I could clearly identify) I wonder not only how a conflict between
the IRQ ranges they use with "normal" IRQs is being avoided, but
also how they can work at all with sparse IRQs, and how races in
trying to set up IRQs' chips/handlers are supposed to be avoided (on
x86, alloc_irq_and_cfg_at() blindly takes the result of
get_irq_chip_data() no matter what ->chip actually points to, and
the call to set_irq_chip_data() is all but race free).

Is it possible that the setup of chained handlers really isn't meant
to be used without precise knowledge of the platform, possibly
including the knowledge that sparse IRQs aren't in use there (and
hence the cited drivers have incomplete Kconfig dependencies)?

While for native x86 it may be that races in setting up IRQ chips
and handlers can be considered implicitly race free (leaving aside
the chained handler situation), under Xen and in the general
case (given that set_irq_chip() and __set_irq_handler() are
exported symbols) currently there seems to be no way to
avoid collisions.

Thanks, Jan