Messages in this thread | | | Date | Fri, 15 Jul 2022 11:48:35 -0500 | From | Bjorn Helgaas <> | Subject | Re: [PATCH] arm: ioremap: Fix compilation of code which use pci_remap_iospace() without CONFIG_MMU |
| |
On Thu, Jul 14, 2022 at 10:19:51PM +0200, Arnd Bergmann wrote: > On Thu, Jul 14, 2022 at 8:57 PM Pali Rohár <pali@kernel.org> wrote: > > Custom ARM version of pci_remap_iospace() is implemented only for MMU > > kernel builds. So do not define pci_remap_iospace() without CONFIG_MMU. > > > > See compilation failures: > > https://lore.kernel.org/r/202112040150.wvyJZIZO-lkp@intel.com/ > > https://lore.kernel.org/r/202112261802.u9iXqdWh-lkp@intel.com/ > > https://lore.kernel.org/r/202201131529.A2s7rKQc-lkp@intel.com/ > > https://lore.kernel.org/r/202203090147.24cUL0De-lkp@intel.com/ > > > > Fixes: bc02973a06a6 ("arm: ioremap: Implement standard PCI function pci_remap_iospace()") > > Reported-by: kernel test robot <lkp@intel.com> > > Signed-off-by: Pali Rohár <pali@kernel.org> > > > > --- > > > > PING!!!! Is somebody interested in fixing these compile errors? As nobody > > answered to my emails where I proposed this fix more than half year ago and > > asked for opinion... > > > > https://lore.kernel.org/r/20211204022131.bmhla4gkph7s7hy2@pali/ > > https://lore.kernel.org/r/20211205123209.lyx76daqdwzqwex4@pali/ > > https://lore.kernel.org/r/20211226215135.blcnafbuwhrq5ram@pali/ > > https://lore.kernel.org/r/20220113134938.3tx7iiukphvazvsq@pali/ > > https://lore.kernel.org/r/20220308184851.jmw2xvrapy5wzwof@pali/ > > Are you sure this still happens in mainline kernels? Since > commit 2f618d5ef5dd ("ARM: remove support for NOMMU ARMv4/v5") > it should no longer be possible to disable the MMU in any Arm machines > other than the Cortex-M based ones, which do not support PCI.
I don't know whether it happens in mainline kernels either.
But even if the 2f618d5ef5dd Kconfiggery makes MMU mostly obsolete for Arm, it seems a little weird that io.h unconditionally promises an arch-specific implementation of pci_remap_iospace(), but we only provide it when CONFIG_MMU=y.
It seems like it'd be a little cleaner if the same condition determined visibility of both the declaration and the definition.
Bjorn
| |