[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] hw/pcie-pci-bridge: restrict to X86 and ARM
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] [PATCH] hw/pcie-pci-bridge: restrict to X86 and ARM |
Date: |
Wed, 8 Nov 2017 18:29:55 +0100 |
On Wed, 8 Nov 2017 19:02:35 +0200
Marcel Apfelbaum <address@hidden> wrote:
> On 08/11/2017 18:52, Thomas Huth wrote:
> > On 08.11.2017 16:20, Marcel Apfelbaum wrote:
> >> The PCIE-PCI bridge is specific to "pure" PCI systems
> >
>
> Hi Thomas,
>
> > s/PCI/PCIe/ ?
> >
>
> In this context maybe it doesn't really matter,
> but if I'll send a v2 I'll make the change, sure.
>
> >> (on QEMU we have X86 and ARM), it does not make sense to
> >> have if in other archs.
If you do a v2 anyway, s/if/it/
> >>
> >> Reported-by: Thomas Huth <address@hidden>
> >> Signed-off-by: Marcel Apfelbaum <address@hidden>
> >> ---
> >> default-configs/arm-softmmu.mak | 1 +
> >> default-configs/i386-softmmu.mak | 1 +
> >> default-configs/x86_64-softmmu.mak | 1 +
> >> hw/pci-bridge/Makefile.objs | 3 ++-
> >> 4 files changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/default-configs/arm-softmmu.mak
> >> b/default-configs/arm-softmmu.mak
> >> index 5059d134c8..33934b1dc4 100644
> >> --- a/default-configs/arm-softmmu.mak
> >> +++ b/default-configs/arm-softmmu.mak
> >> @@ -122,6 +122,7 @@ CONFIG_FSL_IMX25=y
> >> CONFIG_IMX_I2C=y
> >>
> >> CONFIG_PCIE_PORT=y
> >> +CONFIG_PCIE_PCI_BRIDGE=y
> >
> > Actually, why not simply use CONFIG_PCIE_PORT instead to determine
> > whether the PCIe-to-PCI bridge should be included? The device only makes
> > sense if there is a PCIe root port available on the system...
> >
>
> I thought about it, but then we should also change all the devices
> that makes sense only if connected to PCIe Root Ports, like Intel
> Upstream Ports (Switches) and maybe more. (otherwise people will
> start asking why it is different.)
>
> We could use CONFIG_PCIE_PCI_BRIDGE=CONFIG_PCIE_PORT or something
> but it looks weird.
I actually like that one.
>
> This is why I've chosen the "independent" config option.
> But, to be fair, I have nothing against your suggestion,
> let's see what others think.
>
> Thanks for the review,
> Marcel
>
> > Thomas
> >
>