From: Greg KH <gregkh@linuxfoundation.org> To: Michael Kelley <mikelley@microsoft.com> Cc: KY Srinivasan <kys@microsoft.com>, "will.deacon@arm.com" <will.deacon@arm.com>, "catalin.marinas@armm.com" <catalin.marinas@armm.com>, "mark.rutland@arm.com" <mark.rutland@arm.com>, "marc.zyngier@arm.com" <marc.zyngier@arm.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>, "olaf@aepfle.de" <olaf@aepfle.de>, "apw@canonical.com" <apw@canonical.com>, "jasowang@redhat.com" <jasowang@redhat.com>, Stephen Hemminger <sthemmin@microsoft.com>, vkuznets <vkuznets@redhat.com> Subject: Re: [PATCH 3/4] Drivers: hv: vmbus: Add hooks for per-CPU IRQ Date: Tue, 27 Nov 2018 07:20:56 +0100 [thread overview] Message-ID: <20181127062056.GA30285@kroah.com> (raw) In-Reply-To: <CY4PR21MB0773AFA3555BC08A4CC129D4D7D70@CY4PR21MB0773.namprd21.prod.outlook.com> On Mon, Nov 26, 2018 at 08:56:50PM +0000, Michael Kelley wrote: > From: Greg KH <gregkh@linuxfoundation.org> Monday, November 26, 2018 11:57 AM > > > > > You created "null" hooks that do nothing, for no one in this patch > > > > series, why? > > > > > > > > > > hv_enable_vmbus_irq() and hv_disable_vmbus_irq() have non-null > > > implementations in the ARM64 code in patch 2 of this series. The > > > implementations are in the new file arch/arm64/hyperv/mshyperv.c. > > > Or am I misunderstanding your point? > > > > So you use a hook in an earlier patch and then add it in a later one? > > > > Shouldn't you do it the other way around? As it is, the earlier patch > > should not work properly, right? > > The earlier patch implements the hook on the ARM64 side but it is > unused -- it's not called. The later patch then calls it. Wouldn't the > other way around be backwards? Ah, it wasn't obvious that the previous patch added it at all, why not just make that addition part of this patch? > The general approach is for patches 1 and 2 of the series to provide > all the new code under arch/arm64 to enable Hyper-V. But the code > won't get called (or even built) with just these two patches because > CONFIG_HYPERV can't be selected. Patch 3 is separate because it > applies to architecture independent code and arch/x86 code -- I thought > there might be value in keeping the ARM64 and x86 patches distinct. > Patch 4 applies to architecture independent code, and enables the > ARM64 code in patches 1 and 2 to be compiled and run when > CONFIG_HYPERV is selected. > > If combining some of the patches in the series is a better approach, I'm > good with that. Ok, that makes more sense, if it is easier to get the ARM people to review this, that's fine. Doesn't seem like anyone did that yet :( sorry for the noise, greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: gregkh@linuxfoundation.org (Greg KH) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 3/4] Drivers: hv: vmbus: Add hooks for per-CPU IRQ Date: Tue, 27 Nov 2018 07:20:56 +0100 [thread overview] Message-ID: <20181127062056.GA30285@kroah.com> (raw) In-Reply-To: <CY4PR21MB0773AFA3555BC08A4CC129D4D7D70@CY4PR21MB0773.namprd21.prod.outlook.com> On Mon, Nov 26, 2018 at 08:56:50PM +0000, Michael Kelley wrote: > From: Greg KH <gregkh@linuxfoundation.org> Monday, November 26, 2018 11:57 AM > > > > > You created "null" hooks that do nothing, for no one in this patch > > > > series, why? > > > > > > > > > > hv_enable_vmbus_irq() and hv_disable_vmbus_irq() have non-null > > > implementations in the ARM64 code in patch 2 of this series. The > > > implementations are in the new file arch/arm64/hyperv/mshyperv.c. > > > Or am I misunderstanding your point? > > > > So you use a hook in an earlier patch and then add it in a later one? > > > > Shouldn't you do it the other way around? As it is, the earlier patch > > should not work properly, right? > > The earlier patch implements the hook on the ARM64 side but it is > unused -- it's not called. The later patch then calls it. Wouldn't the > other way around be backwards? Ah, it wasn't obvious that the previous patch added it at all, why not just make that addition part of this patch? > The general approach is for patches 1 and 2 of the series to provide > all the new code under arch/arm64 to enable Hyper-V. But the code > won't get called (or even built) with just these two patches because > CONFIG_HYPERV can't be selected. Patch 3 is separate because it > applies to architecture independent code and arch/x86 code -- I thought > there might be value in keeping the ARM64 and x86 patches distinct. > Patch 4 applies to architecture independent code, and enables the > ARM64 code in patches 1 and 2 to be compiled and run when > CONFIG_HYPERV is selected. > > If combining some of the patches in the series is a better approach, I'm > good with that. Ok, that makes more sense, if it is easier to get the ARM people to review this, that's fine. Doesn't seem like anyone did that yet :( sorry for the noise, greg k-h
next prev parent reply other threads:[~2018-11-27 6:21 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-22 3:09 [PATCH 0/4] Hyper-V: Enable Linux guests on Hyper-V on ARM64 kys 2018-11-22 3:09 ` kys at linuxonhyperv.com 2018-11-22 3:10 ` [PATCH 1/4] arm64: hyperv: Add core Hyper-V include files kys 2018-11-22 3:10 ` kys at linuxonhyperv.com 2018-11-22 3:10 ` [PATCH 2/4] arm64: hyperv: Add support for Hyper-V as a hypervisor kys 2018-11-22 3:10 ` kys at linuxonhyperv.com 2018-11-26 19:19 ` Greg KH 2018-11-26 19:19 ` Greg KH 2018-12-07 13:42 ` Will Deacon 2018-12-07 13:42 ` Will Deacon 2018-12-07 14:43 ` Marc Zyngier 2018-12-07 14:43 ` Marc Zyngier 2018-12-12 5:00 ` Michael Kelley 2018-12-12 5:00 ` Michael Kelley 2018-12-13 11:23 ` Marc Zyngier 2018-12-13 11:23 ` Marc Zyngier 2019-01-04 20:05 ` Michael Kelley 2019-01-04 20:05 ` Michael Kelley 2019-01-21 4:38 ` Michael Kelley 2019-01-21 4:38 ` Michael Kelley 2018-11-22 3:10 ` [PATCH 3/4] Drivers: hv: vmbus: Add hooks for per-CPU IRQ kys 2018-11-22 3:10 ` kys at linuxonhyperv.com 2018-11-26 19:21 ` Greg KH 2018-11-26 19:21 ` Greg KH 2018-11-26 19:47 ` Michael Kelley 2018-11-26 19:47 ` Michael Kelley 2018-11-26 19:57 ` Greg KH 2018-11-26 19:57 ` Greg KH 2018-11-26 20:56 ` Michael Kelley 2018-11-26 20:56 ` Michael Kelley 2018-11-27 6:20 ` Greg KH [this message] 2018-11-27 6:20 ` Greg KH 2018-11-27 10:19 ` Will Deacon 2018-11-27 10:19 ` Will Deacon 2018-12-03 1:47 ` Michael Kelley 2018-12-03 1:47 ` Michael Kelley 2018-11-22 3:10 ` [PATCH 4/4] Drivers: hv: Enable CONFIG_HYPERV on ARM64 kys 2018-11-22 3:10 ` kys at linuxonhyperv.com 2018-11-26 19:18 ` [PATCH 1/4] arm64: hyperv: Add core Hyper-V include files Greg KH 2018-11-26 19:18 ` Greg KH 2018-11-26 20:21 ` Joshua R. Poulson 2018-11-26 20:21 ` Joshua R. Poulson 2018-11-27 3:06 ` KY Srinivasan 2018-11-27 3:06 ` KY Srinivasan 2018-12-07 13:42 ` Will Deacon 2018-12-07 13:42 ` Will Deacon 2018-12-12 1:19 ` Michael Kelley 2018-12-12 1:19 ` Michael Kelley 2018-12-10 17:43 ` Vitaly Kuznetsov 2018-12-10 17:43 ` Vitaly Kuznetsov
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=20181127062056.GA30285@kroah.com \ --to=gregkh@linuxfoundation.org \ --cc=apw@canonical.com \ --cc=catalin.marinas@armm.com \ --cc=devel@linuxdriverproject.org \ --cc=jasowang@redhat.com \ --cc=kys@microsoft.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marc.zyngier@arm.com \ --cc=mark.rutland@arm.com \ --cc=mikelley@microsoft.com \ --cc=olaf@aepfle.de \ --cc=sthemmin@microsoft.com \ --cc=vkuznets@redhat.com \ --cc=will.deacon@arm.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: linkBe 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.