On Wed, Oct 12, 2022 at 8:51 AM Michael S. Tsirkin <mst at redhat.com> wrote:> > Are you sure?MichaelE is right. This is just bogus historical garbage:> arch/arm/include/asm/irq.h:#ifndef NO_IRQ > arch/arm/include/asm/irq.h:#define NO_IRQ ((unsigned int)(-1))that I've tried to get rid of for years, but for some reason it just won't die. NO_IRQ should be zero. Or rather, it shouldn't exist at all. It's a bogus thing. You can see just how bogus it is from grepping for it - the users are all completely and utterly confused, and all are entirely historical brokenness. The correct way to check for "no irq" doesn't use NO_IRQ at all, it just does if (dev->irq) ... which is why you will only find a few instances of NO_IRQ in the tree in the first place. The NO_IRQ thing is mainly actually defined by a few drivers that just never got converted to the proper world order, and even then you can see the confusion (ie some drivers use "-1", others use "0", and yet others use "((unsigned int)(-1)". Linus
On Wed, Oct 12, 2022, at 7:22 PM, Linus Torvalds wrote:> > The NO_IRQ thing is mainly actually defined by a few drivers that just > never got converted to the proper world order, and even then you can > see the confusion (ie some drivers use "-1", others use "0", and yet > others use "((unsigned int)(-1)".The last time I looked at removing it for arch/arm/, one problem was that there were a number of platforms using IRQ 0 as a valid number. We have converted most of them in the meantime, leaving now only mach-rpc and mach-footbridge. For the other platforms, we just renumbered all interrupts to add one, but footbridge apparently relies on hardcoded ISA interrupts in device drivers. For rpc, it looks like IRQ 0 (printer) already wouldn't work, and it looks like there was never a driver referencing it either. I see that openrisc and parisc also still define NO_IRQ to -1, but at least openrisc already relies on 0 being the invalid IRQ (from CONFIG_IRQ_DOMAIN), probably parisc as well. Arnd