Re: linux-next: manual merge of the xen-two tree with Linus' tree
>>> On 02.10.12 at 14:55, Konrad Rzeszutek Wilk wrote: > On Tue, Oct 02, 2012 at 12:54:20PM +0100, Jan Beulich wrote: >> >>> On 02.10.12 at 13:45, Stefano Stabellini >> >>> > wrote: >> >> > Considering that dbgp doesn't seem to be very useful without PCI at the >> >> > moment, could we just turn it into: >> >> > >> >> > dom0-$(CONFIG_PCI) += dbgp.o >> >> > >> >> > ? >> >> >> >> Better not - the code is specifically not PCI-only. And I can't see >> >> how it would be harmful to be compiled on e.g. ARM (so the >> >> merge perhaps really should use XEN_DOM0 alone, without >> >> X86. If anything (and that may indeed be a minor oversight of >> >> the original patch) one might want it to depend on USB_SUPPORT, >> >> as without that no in-tree debug port capable driver would be >> >> able to load (and hence interfere with Xen's use of the debug >> >> port). However, as long as it builds fine with USB_SUPPORT >> >> undefined (which I believe it does), having it in the shape it >> >> is allows for out-of-tree drivers as well (as long as they make >> >> use of the designated interface). >> > >> > OK for PCI. >> > Regarding USB_SUPPORT, considering that gbgp.c calls hcd_to_bus, I think >> > it would make sense to make it depend on it. >> >> As said - I'd prefer to do that only if indeed needed to get things >> to build without that option. Since include/usb/* doesn't reference >> CONFIG_USB_SUPPORT, I'm in favor of supporting at least those >> eventual out-of-tree drivers that do use the pre-existing data >> structures (and others shouldn't be calling pre-existing APIs >> anyway). But I wouldn't NAK a patch doing what you suggest >> either. > > Could it depend on EARLY_PRINTK_DBGP ? No, that one would definitely be wrong (because we need the EHCI driver to propagate reset information no matter whether the kernel uses an early console). Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the xen-two tree with Linus' tree
On Tue, Oct 02, 2012 at 12:54:20PM +0100, Jan Beulich wrote: > >>> On 02.10.12 at 13:45, Stefano Stabellini > >>> wrote: > >> > Considering that dbgp doesn't seem to be very useful without PCI at the > >> > moment, could we just turn it into: > >> > > >> > dom0-$(CONFIG_PCI) += dbgp.o > >> > > >> > ? > >> > >> Better not - the code is specifically not PCI-only. And I can't see > >> how it would be harmful to be compiled on e.g. ARM (so the > >> merge perhaps really should use XEN_DOM0 alone, without > >> X86. If anything (and that may indeed be a minor oversight of > >> the original patch) one might want it to depend on USB_SUPPORT, > >> as without that no in-tree debug port capable driver would be > >> able to load (and hence interfere with Xen's use of the debug > >> port). However, as long as it builds fine with USB_SUPPORT > >> undefined (which I believe it does), having it in the shape it > >> is allows for out-of-tree drivers as well (as long as they make > >> use of the designated interface). > > > > OK for PCI. > > Regarding USB_SUPPORT, considering that gbgp.c calls hcd_to_bus, I think > > it would make sense to make it depend on it. > > As said - I'd prefer to do that only if indeed needed to get things > to build without that option. Since include/usb/* doesn't reference > CONFIG_USB_SUPPORT, I'm in favor of supporting at least those > eventual out-of-tree drivers that do use the pre-existing data > structures (and others shouldn't be calling pre-existing APIs > anyway). But I wouldn't NAK a patch doing what you suggest > either. Could it depend on EARLY_PRINTK_DBGP ? > > Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the xen-two tree with Linus' tree
>>> On 02.10.12 at 13:45, Stefano Stabellini >>> wrote: >> > Considering that dbgp doesn't seem to be very useful without PCI at the >> > moment, could we just turn it into: >> > >> > dom0-$(CONFIG_PCI) += dbgp.o >> > >> > ? >> >> Better not - the code is specifically not PCI-only. And I can't see >> how it would be harmful to be compiled on e.g. ARM (so the >> merge perhaps really should use XEN_DOM0 alone, without >> X86. If anything (and that may indeed be a minor oversight of >> the original patch) one might want it to depend on USB_SUPPORT, >> as without that no in-tree debug port capable driver would be >> able to load (and hence interfere with Xen's use of the debug >> port). However, as long as it builds fine with USB_SUPPORT >> undefined (which I believe it does), having it in the shape it >> is allows for out-of-tree drivers as well (as long as they make >> use of the designated interface). > > OK for PCI. > Regarding USB_SUPPORT, considering that gbgp.c calls hcd_to_bus, I think > it would make sense to make it depend on it. As said - I'd prefer to do that only if indeed needed to get things to build without that option. Since include/usb/* doesn't reference CONFIG_USB_SUPPORT, I'm in favor of supporting at least those eventual out-of-tree drivers that do use the pre-existing data structures (and others shouldn't be calling pre-existing APIs anyway). But I wouldn't NAK a patch doing what you suggest either. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the xen-two tree with Linus' tree
On Tue, 2 Oct 2012, Jan Beulich wrote: > >>> On 02.10.12 at 12:44, Stefano Stabellini > >>> wrote: > >> --- a/drivers/xen/Makefile > >> +++ b/drivers/xen/Makefile > >> @@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus > >> nostackp := $(call cc-option, -fno-stack-protector) > >> CFLAGS_features.o:= $(nostackp) > >> > >> + obj-$(CONFIG_XEN_DOM0) += $(dom0-y) > >> + dom0-$(CONFIG_PCI) += pci.o > >> ++dom0-$(CONFIG_X86) += dbgp.o > >> + dom0-$(CONFIG_ACPI) += acpi.o > >> + dom0-$(CONFIG_X86) += pcpu.o > >> obj-$(CONFIG_BLOCK) += biomerge.o > >> - obj-$(CONFIG_HOTPLUG_CPU)+= cpu_hotplug.o > >> obj-$(CONFIG_XEN_XENCOMM)+= xencomm.o > >> obj-$(CONFIG_XEN_BALLOON)+= xen-balloon.o > >> obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o > > > > > > Considering that dbgp doesn't seem to be very useful without PCI at the > > moment, could we just turn it into: > > > > dom0-$(CONFIG_PCI) += dbgp.o > > > > ? > > Better not - the code is specifically not PCI-only. And I can't see > how it would be harmful to be compiled on e.g. ARM (so the > merge perhaps really should use XEN_DOM0 alone, without > X86. If anything (and that may indeed be a minor oversight of > the original patch) one might want it to depend on USB_SUPPORT, > as without that no in-tree debug port capable driver would be > able to load (and hence interfere with Xen's use of the debug > port). However, as long as it builds fine with USB_SUPPORT > undefined (which I believe it does), having it in the shape it > is allows for out-of-tree drivers as well (as long as they make > use of the designated interface). OK for PCI. Regarding USB_SUPPORT, considering that gbgp.c calls hcd_to_bus, I think it would make sense to make it depend on it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the xen-two tree with Linus' tree
>>> On 02.10.12 at 12:44, Stefano Stabellini >>> wrote: >> --- a/drivers/xen/Makefile >> +++ b/drivers/xen/Makefile >> @@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus >> nostackp := $(call cc-option, -fno-stack-protector) >> CFLAGS_features.o := $(nostackp) >> >> + obj-$(CONFIG_XEN_DOM0) += $(dom0-y) >> + dom0-$(CONFIG_PCI) += pci.o >> ++dom0-$(CONFIG_X86) += dbgp.o >> + dom0-$(CONFIG_ACPI) += acpi.o >> + dom0-$(CONFIG_X86) += pcpu.o >> obj-$(CONFIG_BLOCK)+= biomerge.o >> - obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o >> obj-$(CONFIG_XEN_XENCOMM) += xencomm.o >> obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o >> obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o > > > Considering that dbgp doesn't seem to be very useful without PCI at the > moment, could we just turn it into: > > dom0-$(CONFIG_PCI) += dbgp.o > > ? Better not - the code is specifically not PCI-only. And I can't see how it would be harmful to be compiled on e.g. ARM (so the merge perhaps really should use XEN_DOM0 alone, without X86. If anything (and that may indeed be a minor oversight of the original patch) one might want it to depend on USB_SUPPORT, as without that no in-tree debug port capable driver would be able to load (and hence interfere with Xen's use of the debug port). However, as long as it builds fine with USB_SUPPORT undefined (which I believe it does), having it in the shape it is allows for out-of-tree drivers as well (as long as they make use of the designated interface). Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the xen-two tree with Linus' tree
On Tue, 2 Oct 2012, Stephen Rothwell wrote:
> Hi Konrad,
>
> Today's linux-next merge of the xen-two tree got a conflict in
> drivers/xen/Makefile between commit 9fa5780beea1 ("USB EHCI/Xen:
> propagate controller reset information to hypervisor") from Linus' tree
> and commit 13febc84849d ("xen: do not compile manage, balloon, pci, acpi,
> pcpu and cpu_hotplug on ARM") from the xen-two tree.
>
> I fixed it up (I am not sure exactly what it should depend on - see
> below) and can carry the fix as necessary (no action is required).
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/xen/Makefile
> index a4a3cab,cd28aae..000
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@@ -4,8 -8,11 +8,12 @@@ obj-y+= xenbus
> nostackp := $(call cc-option, -fno-stack-protector)
> CFLAGS_features.o := $(nostackp)
>
> + obj-$(CONFIG_XEN_DOM0) += $(dom0-y)
> + dom0-$(CONFIG_PCI) += pci.o
> ++dom0-$(CONFIG_X86) += dbgp.o
> + dom0-$(CONFIG_ACPI) += acpi.o
> + dom0-$(CONFIG_X86) += pcpu.o
> obj-$(CONFIG_BLOCK) += biomerge.o
> - obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o
> obj-$(CONFIG_XEN_XENCOMM) += xencomm.o
> obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o
> obj-$(CONFIG_XEN_SELFBALLOONING)+= xen-selfballoon.o
Considering that dbgp doesn't seem to be very useful without PCI at the
moment, could we just turn it into:
dom0-$(CONFIG_PCI) += dbgp.o
?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the xen-two tree with Linus' tree
On Tue, 2 Oct 2012, Stephen Rothwell wrote: Hi Konrad, Today's linux-next merge of the xen-two tree got a conflict in drivers/xen/Makefile between commit 9fa5780beea1 (USB EHCI/Xen: propagate controller reset information to hypervisor) from Linus' tree and commit 13febc84849d (xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM) from the xen-two tree. I fixed it up (I am not sure exactly what it should depend on - see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/xen/Makefile index a4a3cab,cd28aae..000 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@@ -4,8 -8,11 +8,12 @@@ obj-y+= xenbus nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) + obj-$(CONFIG_XEN_DOM0) += $(dom0-y) + dom0-$(CONFIG_PCI) += pci.o ++dom0-$(CONFIG_X86) += dbgp.o + dom0-$(CONFIG_ACPI) += acpi.o + dom0-$(CONFIG_X86) += pcpu.o obj-$(CONFIG_BLOCK) += biomerge.o - obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o obj-$(CONFIG_XEN_XENCOMM) += xencomm.o obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o obj-$(CONFIG_XEN_SELFBALLOONING)+= xen-selfballoon.o Considering that dbgp doesn't seem to be very useful without PCI at the moment, could we just turn it into: dom0-$(CONFIG_PCI) += dbgp.o ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the xen-two tree with Linus' tree
On 02.10.12 at 12:44, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) + obj-$(CONFIG_XEN_DOM0) += $(dom0-y) + dom0-$(CONFIG_PCI) += pci.o ++dom0-$(CONFIG_X86) += dbgp.o + dom0-$(CONFIG_ACPI) += acpi.o + dom0-$(CONFIG_X86) += pcpu.o obj-$(CONFIG_BLOCK)+= biomerge.o - obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o obj-$(CONFIG_XEN_XENCOMM) += xencomm.o obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o Considering that dbgp doesn't seem to be very useful without PCI at the moment, could we just turn it into: dom0-$(CONFIG_PCI) += dbgp.o ? Better not - the code is specifically not PCI-only. And I can't see how it would be harmful to be compiled on e.g. ARM (so the merge perhaps really should use XEN_DOM0 alone, without X86. If anything (and that may indeed be a minor oversight of the original patch) one might want it to depend on USB_SUPPORT, as without that no in-tree debug port capable driver would be able to load (and hence interfere with Xen's use of the debug port). However, as long as it builds fine with USB_SUPPORT undefined (which I believe it does), having it in the shape it is allows for out-of-tree drivers as well (as long as they make use of the designated interface). Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the xen-two tree with Linus' tree
On Tue, 2 Oct 2012, Jan Beulich wrote: On 02.10.12 at 12:44, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o:= $(nostackp) + obj-$(CONFIG_XEN_DOM0) += $(dom0-y) + dom0-$(CONFIG_PCI) += pci.o ++dom0-$(CONFIG_X86) += dbgp.o + dom0-$(CONFIG_ACPI) += acpi.o + dom0-$(CONFIG_X86) += pcpu.o obj-$(CONFIG_BLOCK) += biomerge.o - obj-$(CONFIG_HOTPLUG_CPU)+= cpu_hotplug.o obj-$(CONFIG_XEN_XENCOMM)+= xencomm.o obj-$(CONFIG_XEN_BALLOON)+= xen-balloon.o obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o Considering that dbgp doesn't seem to be very useful without PCI at the moment, could we just turn it into: dom0-$(CONFIG_PCI) += dbgp.o ? Better not - the code is specifically not PCI-only. And I can't see how it would be harmful to be compiled on e.g. ARM (so the merge perhaps really should use XEN_DOM0 alone, without X86. If anything (and that may indeed be a minor oversight of the original patch) one might want it to depend on USB_SUPPORT, as without that no in-tree debug port capable driver would be able to load (and hence interfere with Xen's use of the debug port). However, as long as it builds fine with USB_SUPPORT undefined (which I believe it does), having it in the shape it is allows for out-of-tree drivers as well (as long as they make use of the designated interface). OK for PCI. Regarding USB_SUPPORT, considering that gbgp.c calls hcd_to_bus, I think it would make sense to make it depend on it. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the xen-two tree with Linus' tree
On 02.10.12 at 13:45, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: Considering that dbgp doesn't seem to be very useful without PCI at the moment, could we just turn it into: dom0-$(CONFIG_PCI) += dbgp.o ? Better not - the code is specifically not PCI-only. And I can't see how it would be harmful to be compiled on e.g. ARM (so the merge perhaps really should use XEN_DOM0 alone, without X86. If anything (and that may indeed be a minor oversight of the original patch) one might want it to depend on USB_SUPPORT, as without that no in-tree debug port capable driver would be able to load (and hence interfere with Xen's use of the debug port). However, as long as it builds fine with USB_SUPPORT undefined (which I believe it does), having it in the shape it is allows for out-of-tree drivers as well (as long as they make use of the designated interface). OK for PCI. Regarding USB_SUPPORT, considering that gbgp.c calls hcd_to_bus, I think it would make sense to make it depend on it. As said - I'd prefer to do that only if indeed needed to get things to build without that option. Since include/usb/* doesn't reference CONFIG_USB_SUPPORT, I'm in favor of supporting at least those eventual out-of-tree drivers that do use the pre-existing data structures (and others shouldn't be calling pre-existing APIs anyway). But I wouldn't NAK a patch doing what you suggest either. Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the xen-two tree with Linus' tree
On Tue, Oct 02, 2012 at 12:54:20PM +0100, Jan Beulich wrote: On 02.10.12 at 13:45, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: Considering that dbgp doesn't seem to be very useful without PCI at the moment, could we just turn it into: dom0-$(CONFIG_PCI) += dbgp.o ? Better not - the code is specifically not PCI-only. And I can't see how it would be harmful to be compiled on e.g. ARM (so the merge perhaps really should use XEN_DOM0 alone, without X86. If anything (and that may indeed be a minor oversight of the original patch) one might want it to depend on USB_SUPPORT, as without that no in-tree debug port capable driver would be able to load (and hence interfere with Xen's use of the debug port). However, as long as it builds fine with USB_SUPPORT undefined (which I believe it does), having it in the shape it is allows for out-of-tree drivers as well (as long as they make use of the designated interface). OK for PCI. Regarding USB_SUPPORT, considering that gbgp.c calls hcd_to_bus, I think it would make sense to make it depend on it. As said - I'd prefer to do that only if indeed needed to get things to build without that option. Since include/usb/* doesn't reference CONFIG_USB_SUPPORT, I'm in favor of supporting at least those eventual out-of-tree drivers that do use the pre-existing data structures (and others shouldn't be calling pre-existing APIs anyway). But I wouldn't NAK a patch doing what you suggest either. Could it depend on EARLY_PRINTK_DBGP ? Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the xen-two tree with Linus' tree
On 02.10.12 at 14:55, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Tue, Oct 02, 2012 at 12:54:20PM +0100, Jan Beulich wrote: On 02.10.12 at 13:45, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: Considering that dbgp doesn't seem to be very useful without PCI at the moment, could we just turn it into: dom0-$(CONFIG_PCI) += dbgp.o ? Better not - the code is specifically not PCI-only. And I can't see how it would be harmful to be compiled on e.g. ARM (so the merge perhaps really should use XEN_DOM0 alone, without X86. If anything (and that may indeed be a minor oversight of the original patch) one might want it to depend on USB_SUPPORT, as without that no in-tree debug port capable driver would be able to load (and hence interfere with Xen's use of the debug port). However, as long as it builds fine with USB_SUPPORT undefined (which I believe it does), having it in the shape it is allows for out-of-tree drivers as well (as long as they make use of the designated interface). OK for PCI. Regarding USB_SUPPORT, considering that gbgp.c calls hcd_to_bus, I think it would make sense to make it depend on it. As said - I'd prefer to do that only if indeed needed to get things to build without that option. Since include/usb/* doesn't reference CONFIG_USB_SUPPORT, I'm in favor of supporting at least those eventual out-of-tree drivers that do use the pre-existing data structures (and others shouldn't be calling pre-existing APIs anyway). But I wouldn't NAK a patch doing what you suggest either. Could it depend on EARLY_PRINTK_DBGP ? No, that one would definitely be wrong (because we need the EHCI driver to propagate reset information no matter whether the kernel uses an early console). Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
