xen/drivers/passthrough/arm/ipmmu-vmsa.c | 2 ++ 1 file changed, 2 insertions(+)
With PCI disabled the build fails due to undefined struct
pci_host_bridge.
Add ifdef guard around pci-host-rcar4.h to not include it when PCI
support is disabled.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
---
This patch can be squashed with iommu/ipmmu-vmsa: Implement basic PCIE-IPMMU OSID support
---
xen/drivers/passthrough/arm/ipmmu-vmsa.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
index ea9fa9ddf3..49f149e222 100644
--- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
+++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
@@ -51,7 +51,9 @@
#include <asm/device.h>
#include <asm/io.h>
#include <asm/iommu_fwspec.h>
+#ifdef CONFIG_HAS_PCI
#include "../arch/arm/pci/pci-host-rcar4.h"
+#endif
#define dev_name(dev) dt_node_full_name(dev_to_dt(dev))
--
2.34.1
Hi Mykyta, On Thu, Aug 21, 2025 at 1:51 PM Mykyta Poturai <Mykyta_Poturai@epam.com> wrote: > > With PCI disabled the build fails due to undefined struct > pci_host_bridge. > > Add ifdef guard around pci-host-rcar4.h to not include it when PCI > support is disabled. > > Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com> > --- > This patch can be squashed with iommu/ipmmu-vmsa: Implement basic PCIE-IPMMU OSID support > --- > xen/drivers/passthrough/arm/ipmmu-vmsa.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c > index ea9fa9ddf3..49f149e222 100644 > --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c > +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c > @@ -51,7 +51,9 @@ > #include <asm/device.h> > #include <asm/io.h> > #include <asm/iommu_fwspec.h> > +#ifdef CONFIG_HAS_PCI > #include "../arch/arm/pci/pci-host-rcar4.h" > +#endif As far as I know, the IPMMU VMSA driver can also be used on other R-Car platforms. Is there a chance we could have HAS_PCI enabled together with IPMMU VMSA, but not be on an R-Car Gen4 platform, for example, on R-Car3 or possibly some future R-Car variants? Wouldn't it be better to use: #ifdef CONFIG_RCAR4 ? > > #define dev_name(dev) dt_node_full_name(dev_to_dt(dev)) > > -- > 2.34.1 > Best regards, Mykola
On 21.08.25 15:03, Mykola Kvach wrote: > Hi Mykyta, > > On Thu, Aug 21, 2025 at 1:51 PM Mykyta Poturai <Mykyta_Poturai@epam.com> wrote: >> >> With PCI disabled the build fails due to undefined struct >> pci_host_bridge. >> >> Add ifdef guard around pci-host-rcar4.h to not include it when PCI >> support is disabled. >> >> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com> >> --- >> This patch can be squashed with iommu/ipmmu-vmsa: Implement basic PCIE-IPMMU OSID support >> --- >> xen/drivers/passthrough/arm/ipmmu-vmsa.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c >> index ea9fa9ddf3..49f149e222 100644 >> --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c >> +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c >> @@ -51,7 +51,9 @@ >> #include <asm/device.h> >> #include <asm/io.h> >> #include <asm/iommu_fwspec.h> >> +#ifdef CONFIG_HAS_PCI >> #include "../arch/arm/pci/pci-host-rcar4.h" >> +#endif > > As far as I know, the IPMMU VMSA driver can also be used on other > R-Car platforms. Is there a chance we could have HAS_PCI enabled > together with IPMMU VMSA, but not be on an R-Car Gen4 platform, > for example, on R-Car3 or possibly some future R-Car variants? > > Wouldn't it be better to use: > #ifdef CONFIG_RCAR4 > ? Gen5 boards will use SMMU, so this will not be applicable to them. In any case, checking for RCAR4 will not help here, as PCI can be disabled regardless of the platform revision. > > Best regards, > Mykola -- Mykyta
On Thu, Aug 21, 2025 at 4:09 PM Mykyta Poturai <Mykyta_Poturai@epam.com> wrote: > > On 21.08.25 15:03, Mykola Kvach wrote: > > Hi Mykyta, > > > > On Thu, Aug 21, 2025 at 1:51 PM Mykyta Poturai <Mykyta_Poturai@epam.com> wrote: > >> > >> With PCI disabled the build fails due to undefined struct > >> pci_host_bridge. > >> > >> Add ifdef guard around pci-host-rcar4.h to not include it when PCI > >> support is disabled. > >> > >> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com> > >> --- > >> This patch can be squashed with iommu/ipmmu-vmsa: Implement basic PCIE-IPMMU OSID support > >> --- > >> xen/drivers/passthrough/arm/ipmmu-vmsa.c | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c > >> index ea9fa9ddf3..49f149e222 100644 > >> --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c > >> +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c > >> @@ -51,7 +51,9 @@ > >> #include <asm/device.h> > >> #include <asm/io.h> > >> #include <asm/iommu_fwspec.h> > >> +#ifdef CONFIG_HAS_PCI > >> #include "../arch/arm/pci/pci-host-rcar4.h" > >> +#endif > > > > As far as I know, the IPMMU VMSA driver can also be used on other > > R-Car platforms. Is there a chance we could have HAS_PCI enabled > > together with IPMMU VMSA, but not be on an R-Car Gen4 platform, > > for example, on R-Car3 or possibly some future R-Car variants? > > > > Wouldn't it be better to use: > > #ifdef CONFIG_RCAR4 > > ? > > Gen5 boards will use SMMU, so this will not be applicable to them. In > any case, checking for RCAR4 will not help here, as PCI can be disabled > regardless of the platform revision. I see your point that CONFIG_RCAR4 alone isn’t enough, since PCI can be disabled even on Gen4. My concern is that we’re adding Gen4-specific code into a generic IPMMU VMSA driver, which is used on multiple R-Car generations. > > > > > Best regards, > > Mykola > > -- > Mykyta
On 21.08.2025 12:50, Mykyta Poturai wrote: > With PCI disabled the build fails due to undefined struct > pci_host_bridge. > > Add ifdef guard around pci-host-rcar4.h to not include it when PCI > support is disabled. > > Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com> Oh, and - Reported-by: ... please. Jan
On 21.08.2025 12:50, Mykyta Poturai wrote: > --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c > +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c > @@ -51,7 +51,9 @@ > #include <asm/device.h> > #include <asm/io.h> > #include <asm/iommu_fwspec.h> > +#ifdef CONFIG_HAS_PCI > #include "../arch/arm/pci/pci-host-rcar4.h" > +#endif > > #define dev_name(dev) dt_node_full_name(dev_to_dt(dev)) Hmm, while this may take care of the immediate issue, I wonder if it wouldn't better be the header itself which is modified. Then perhaps also taking care of the other (Misra) issue there: The header guard check not being first in the file, but sitting after an #include. I further assume there is a good reason why a private header is included here from some other subtree. Jan
© 2016 - 2025 Red Hat, Inc.