From: "Michael S. Tsirkin" <mst@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
xiujianfeng@huawei.com, kvm@vger.kernel.org,
alvaro.karsz@solid-run.com, Jason Wang <jasowang@redhat.com>,
angus.chen@jaguarmicro.com, wangdeming@inspur.com,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Netdev <netdev@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
lingshan.zhu@intel.com, linuxppc-dev@lists.ozlabs.org,
gavinl@nvidia.com
Subject: Re: [GIT PULL] virtio: fixes, features
Date: Wed, 12 Oct 2022 18:08:27 -0400 [thread overview]
Message-ID: <20221012180806-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <38893b2e-c7a1-4ad2-b691-7fbcbbeb310f@app.fastmail.com>
On Wed, Oct 12, 2022 at 11:06:54PM +0200, Arnd Bergmann wrote:
> 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.
Do these two boxes even have pci?
> 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
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: xiujianfeng@huawei.com, kvm@vger.kernel.org,
alvaro.karsz@solid-run.com, linux-pci@vger.kernel.org,
Jason Wang <jasowang@redhat.com>,
linuxppc-dev@lists.ozlabs.org, wangdeming@inspur.com,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Netdev <netdev@vger.kernel.org>,
angus.chen@jaguarmicro.com, Bjorn Helgaas <bhelgaas@google.com>,
lingshan.zhu@intel.com,
Linus Torvalds <torvalds@linux-foundation.org>,
gavinl@nvidia.com
Subject: Re: [GIT PULL] virtio: fixes, features
Date: Wed, 12 Oct 2022 18:08:27 -0400 [thread overview]
Message-ID: <20221012180806-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <38893b2e-c7a1-4ad2-b691-7fbcbbeb310f@app.fastmail.com>
On Wed, Oct 12, 2022 at 11:06:54PM +0200, Arnd Bergmann wrote:
> 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.
Do these two boxes even have pci?
> 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
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: xiujianfeng@huawei.com, kvm@vger.kernel.org,
linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
wangdeming@inspur.com, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Netdev <netdev@vger.kernel.org>,
angus.chen@jaguarmicro.com, Bjorn Helgaas <bhelgaas@google.com>,
lingshan.zhu@intel.com,
Linus Torvalds <torvalds@linux-foundation.org>,
gavinl@nvidia.com
Subject: Re: [GIT PULL] virtio: fixes, features
Date: Wed, 12 Oct 2022 18:08:27 -0400 [thread overview]
Message-ID: <20221012180806-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <38893b2e-c7a1-4ad2-b691-7fbcbbeb310f@app.fastmail.com>
On Wed, Oct 12, 2022 at 11:06:54PM +0200, Arnd Bergmann wrote:
> 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.
Do these two boxes even have pci?
> 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
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2022-10-12 22:10 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-10 17:20 [GIT PULL] virtio: fixes, features Michael S. Tsirkin
2022-10-10 17:20 ` Michael S. Tsirkin
2022-10-10 21:23 ` pr-tracker-bot
2022-10-10 21:23 ` pr-tracker-bot
2022-10-12 6:21 ` Michael Ellerman
2022-10-12 6:21 ` Michael Ellerman
2022-10-12 6:21 ` Michael Ellerman
2022-10-12 6:45 ` Angus Chen
2022-10-12 6:45 ` Angus Chen
2022-10-12 7:35 ` Angus Chen
2022-10-12 7:35 ` Angus Chen
2022-10-12 11:11 ` Michael S. Tsirkin
2022-10-12 11:11 ` Michael S. Tsirkin
2022-10-12 11:11 ` Michael S. Tsirkin
2022-10-12 13:28 ` Michael Ellerman
2022-10-12 13:28 ` Michael Ellerman
2022-10-12 13:28 ` Michael Ellerman
2022-10-12 14:33 ` Michael Ellerman
2022-10-12 14:33 ` Michael Ellerman
2022-10-12 14:33 ` Michael Ellerman
2022-10-12 15:51 ` Michael S. Tsirkin
2022-10-12 15:51 ` Michael S. Tsirkin
2022-10-12 15:51 ` Michael S. Tsirkin
2022-10-12 17:22 ` Linus Torvalds
2022-10-12 17:22 ` Linus Torvalds
2022-10-12 17:22 ` Linus Torvalds
2022-10-12 21:06 ` Arnd Bergmann
2022-10-12 21:06 ` Arnd Bergmann
2022-10-12 21:06 ` Arnd Bergmann
2022-10-12 22:08 ` Michael S. Tsirkin [this message]
2022-10-12 22:08 ` Michael S. Tsirkin
2022-10-12 22:08 ` Michael S. Tsirkin
2022-10-13 6:28 ` Arnd Bergmann
2022-10-13 6:28 ` Arnd Bergmann
2022-10-13 6:28 ` Arnd Bergmann
2022-10-13 17:19 ` Linus Torvalds
2022-10-13 17:19 ` Linus Torvalds
2022-10-13 17:19 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221012180806-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alvaro.karsz@solid-run.com \
--cc=angus.chen@jaguarmicro.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=gavinl@nvidia.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=lingshan.zhu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=wangdeming@inspur.com \
--cc=xiujianfeng@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.