[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <38893b2e-c7a1-4ad2-b691-7fbcbbeb310f@app.fastmail.com>
Date: Wed, 12 Oct 2022 23:06:54 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Linus Torvalds" <torvalds@...ux-foundation.org>,
"Michael S. Tsirkin" <mst@...hat.com>
Cc: xiujianfeng@...wei.com, kvm@...r.kernel.org,
alvaro.karsz@...id-run.com, "Jason Wang" <jasowang@...hat.com>,
angus.chen@...uarmicro.com, wangdeming@...pur.com,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
Netdev <netdev@...r.kernel.org>,
"Bjorn Helgaas" <bhelgaas@...gle.com>, lingshan.zhu@...el.com,
linuxppc-dev@...ts.ozlabs.org, gavinl@...dia.com
Subject: Re: [GIT PULL] virtio: fixes, features
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
Powered by blists - more mailing lists