[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MW2PR2101MB1052B9C24DAB19FBBD818347D7F70@MW2PR2101MB1052.namprd21.prod.outlook.com>
Date: Wed, 18 Mar 2020 00:16:24 +0000
From: Michael Kelley <mikelley@...rosoft.com>
To: Arnd Bergmann <arnd@...db.de>
CC: Will Deacon <will@...nel.org>, Ard Biesheuvel <ardb@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Mark Rutland <mark.rutland@....com>,
Marc Zyngier <maz@...nel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
gregkh <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
linux-efi <linux-efi@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
"olaf@...fle.de" <olaf@...fle.de>,
Andy Whitcroft <apw@...onical.com>,
vkuznets <vkuznets@...hat.com>, Jason Wang <jasowang@...hat.com>,
"marcelo.cerri@...onical.com" <marcelo.cerri@...onical.com>,
KY Srinivasan <kys@...rosoft.com>,
Sunil Muthuswamy <sunilmut@...rosoft.com>,
Boqun Feng <boqun.feng@...il.com>
Subject: RE: [PATCH v6 05/10] arm64: hyperv: Add interrupt handlers for VMbus
and stimer
From: Arnd Bergmann <arnd@...db.de>
>
> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <mikelley@...rosoft.com> wrote:
> >
> > Add ARM64-specific code to set up and handle the interrupts
> > generated by Hyper-V for VMbus messages and for stimer expiration.
> >
> > This code is architecture dependent and is mostly driven by
> > architecture independent code in the VMbus driver and the
> > Hyper-V timer clocksource driver.
> >
> > This code is built only when CONFIG_HYPERV is enabled.
> >
> > Signed-off-by: Michael Kelley <mikelley@...rosoft.com>
>
> This looks like it should be a nested irqchip driver instead, so your
> device drivers can use the normal request_irq() functions etc.
>
> Is anything preventing you from doing that? If so, please describe
> that in the changelog and in a comment in the driver.
>
As mentioned in my reply on Patch 1, Hyper-V offers a limited synthetic
interrupt controller managed by Linux code that's been around the last
10 years on the x86 side. For reasons that pre-date me, it was not written
as an irqchip driver.
Modulo the small routines you see in this patch, the code is architecture
independent, and it seems we ought to keep the high degree of commonality.
Re-architecting the arch independent code to model as an irqchip driver seems
to carry some risk to the x86 side that has a lot of real-world usage today, but
I'll take a look and see what the risks look like and if it adds any clarity.
Powered by blists - more mailing lists