On Tue, 2024-01-23 at 14:20 -0600, Bjorn Helgaas wrote: > On Thu, Jan 11, 2024 at 09:55:37AM +0100, Philipp Stanner wrote: > > This file is guarded by an #ifdef CONFIG_PCI. It, consequently, > > does not > > belong to lib/ because it is not generic infrastructure. > > > > Move the file to drivers/pci/ and implement the necessary changes > > to > > Makefiles and Kconfigs. > > ... > > > --- a/drivers/pci/Kconfig > > +++ b/drivers/pci/Kconfig > > @@ -13,6 +13,11 @@ config FORCE_PCI > > select HAVE_PCI > > select PCI > > > > +# select this to provide a generic PCI iomap, > > +# without PCI itself having to be defined > > +config GENERIC_PCI_IOMAP > > + bool > > > --- a/lib/pci_iomap.c > > +++ b/drivers/pci/iomap.c > > @@ -9,7 +9,6 @@ > > > > #include <linux/export.h> > > > > -#ifdef CONFIG_PCI > > IIUC, in the case where CONFIG_GENERIC_PCI_IOMAP=y but CONFIG_PCI was > not set, pci_iomap.c was compiled but produced no code because the > entire file was wrapped with this #ifdef. > > But after this patch, it looks like pci_iomap_range(), > pci_iomap_wc_range(), etc., *will* be compiled? > > Is that what you intend, or did I miss something? They *will* be compiled when BOTH, CONFIG_PCI and CONFIG_GENERIC_PCI_IOMAP have been set. It's a bit hard to see that in the patch's diff. Here, look closely: --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -14,6 +14,7 @@ ifdef CONFIG_PCI <----------- obj-$(CONFIG_PROC_FS) += proc.o obj-$(CONFIG_SYSFS) += slot.o obj-$(CONFIG_ACPI) += pci-acpi.o +obj-$(CONFIG_GENERIC_PCI_IOMAP) += iomap.o <------------ endif So if I am not mistaken it behaves 100% as it did before I prefered Makefile-logic over even more C Preprocessor to implement that. The preprocessor has caused us so much trouble... :( P. > > Bjorn >