The driver's module init function, pcifront_init(), invokes
xen_pv_domain() first thing. That construct produces constant "false"
when !CONFIG_XEN_PV. Hence there's no point building the driver in
non-PV configurations.
Drop the (now implicit and generally wrong) X86 dependency: At present,
XEN_PV con only be set when X86 is also enabled. In general an
architecture supporting Xen PV (and PCI) would want to have this driver
built.
Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Stefano Stabellini <[email protected]>
---
v2: Title and description redone.
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -110,7 +110,7 @@ config PCI_PF_STUB
config XEN_PCIDEV_FRONTEND
tristate "Xen PCI Frontend"
- depends on X86 && XEN
+ depends on XEN_PV
select PCI_XEN
select XEN_XENBUS_FRONTEND
default y
s/only/Only/ in subject
On Fri, Sep 17, 2021 at 12:48:03PM +0200, Jan Beulich wrote:
> The driver's module init function, pcifront_init(), invokes
> xen_pv_domain() first thing. That construct produces constant "false"
> when !CONFIG_XEN_PV. Hence there's no point building the driver in
> non-PV configurations.
Thanks for these bread crumbs. xen_domain_type is set to
XEN_PV_DOMAIN only by xen_start_kernel() in enlighten_pv.c, which is
only built when CONFIG_XEN_PV=y, so even I can verify this :)
> Drop the (now implicit and generally wrong) X86 dependency: At present,
> XEN_PV con only be set when X86 is also enabled. In general an
> architecture supporting Xen PV (and PCI) would want to have this driver
> built.
s/con only/can only/
> Signed-off-by: Jan Beulich <[email protected]>
> Reviewed-by: Stefano Stabellini <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
> ---
> v2: Title and description redone.
>
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -110,7 +110,7 @@ config PCI_PF_STUB
>
> config XEN_PCIDEV_FRONTEND
> tristate "Xen PCI Frontend"
> - depends on X86 && XEN
> + depends on XEN_PV
> select PCI_XEN
> select XEN_XENBUS_FRONTEND
> default y
>