Re: [PATCH v3 09/11] s390: mm: Convert to GENERIC_IOREMAP

[Baoquan He]

On 10/10/22 at 01:53pm, Niklas Schnelle wrote:
> On Mon, 2022-10-10 at 18:38 +0800, Baoquan He wrote:
> > On 10/09/22 at 09:54pm, kernel test robot wrote:
> > > Hi Baoquan,
> > > 
> > > I love your patch! Yet something to improve:
> > > 
> > > [auto build test ERROR on linus/master]
> > > [also build test ERROR on next-20221007]
> > > [cannot apply to akpm-mm/mm-everything openrisc/for-next deller-parisc/for-next s390/features v6.0]
> > > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > > And when submitting patch, we suggest to use '--base' as documented in
> > > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > > 
> > > url:    https://github.com/intel-lab-lkp/linux/commits/Baoquan-He/mm-ioremap-Convert-architectures-to-take-GENERIC_IOREMAP-way/20221009-183524
> > > base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git a6afa4199d3d038fbfdff5511f7523b0e30cb774
> > > config: s390-buildonly-randconfig-r006-20221009
> > > compiler: s390-linux-gcc (GCC) 12.1.0
> > > reproduce (this is a W=1 build):
> > >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > >         chmod +x ~/bin/make.cross
> > >         # https://github.com/intel-lab-lkp/linux/commit/69f65149d2e87de076edbb2b4dd9532f8f57dd8b
> > >         git remote add linux-review https://github.com/intel-lab-lkp/linux
> > >         git fetch --no-tags linux-review Baoquan-He/mm-ioremap-Convert-architectures-to-take-GENERIC_IOREMAP-way/20221009-183524
> > >         git checkout 69f65149d2e87de076edbb2b4dd9532f8f57dd8b
> > >         # save the config file
> > >         mkdir build_dir && cp config build_dir/.config
> > >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=s390 SHELL=/bin/bash
> > > 
> > > If you fix the issue, kindly add following tag where applicable
> > > > Reported-by: kernel test robot <lkp@xxxxxxxxx>
> > > 
> > > All errors (new ones prefixed by >>):
> > > 
> > >    s390-linux-ld: mm/ioremap.o: in function `ioremap_prot':
> > > > > ioremap.c:(.text+0x9a): undefined reference to `arch_ioremap'
> > >    s390-linux-ld: mm/ioremap.o: in function `iounmap':
> > > > > ioremap.c:(.text+0x234): undefined reference to `arch_iounmap'
> > >    s390-linux-ld: drivers/dma/qcom/hidma.o: in function `hidma_probe':
> > >    hidma.c:(.text+0x4b46): undefined reference to `devm_ioremap_resource'
> > >    s390-linux-ld: hidma.c:(.text+0x4b9e): undefined reference to `devm_ioremap_resource'
> > 
> > The above compiling errors are caused by unsetting CONFIG_PCI in
> > s390-buildonly-randconfig-r006-20221009 attached. I keep the items for
> > reference. Because s390 puts io mem functions in arch/s390/pci/pci.c.
> > While building arch/s390/pci/pci.c in needs CONFIG_PCI enabled. I don't
> > think disabling CONFIG_PCI in s390x makes sense in reality, except of
> > the randconfig testing.
> > 
> > Hi Niklas, lkp
> > 
> > What do you think about this? We can just ignore this building error
> > with randconfig in lkp?
> 
> Hmm, that's a bummer. As s390 systems (aka mainframes) do have classic
> channel devices for networking and permanent storage that are currently
> even more common than PCI devices you can definitely have a fully
> functional system with CONFIG_PCI=n. Also the drivers for these channel
> devices do not use ioremap() which is only used for PCI, so in theory
> it should be fine not to have ioremap() for CONFIG_PCI=n.

Thanks for detailed explanation.

I built the latest upstream kernel with the randconfig, it has the issue
either, please see below build log snippet. Means if CONFIG_PCI is unset,
it has problem with the current s390 code.

ld: drivers/dma/qcom/hidma.o: in function `hidma_probe':
hidma.c:(.text+0x4b46): undefined reference to `devm_ioremap_resource'
ld: hidma.c:(.text+0x4b9e): undefined reference to `devm_ioremap_resource'
ld: drivers/pcmcia/cistpl.o: in function `set_cis_map':
cistpl.c:(.text+0x1202): undefined reference to `ioremap'
ld: cistpl.c:(.text+0x13b0): undefined reference to `iounmap'
ld: cistpl.c:(.text+0x14a6): undefined reference to `iounmap'
ld: cistpl.c:(.text+0x1544): undefined reference to `ioremap'
ld: drivers/pcmcia/cistpl.o: in function `release_cis_mem':
cistpl.c:(.text+0x3f14): undefined reference to `iounmap'
make[1]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1
make: *** [Makefile:1235: vmlinux] Error 2

> 
> I think the reason for this concrete failure to compile is a missing
> HAS_IOMEM dependency for CONFIG_QCOM_HIDMA. I'm not sure how many other
> cases there are though as I think we might be the only ones where
> HAS_IOMEM is only sometimes available (it depends on CONFIG_PCI for
> us). Ideally I think we would have the driver dependencies. I'm a bit
> confused though since in the current code it looks to me like
> ioremap_prot() will be declared but not defined for CONFIG_PCI=n too as
> far as I can tell at least.

Yeah, depending on HAS_IOMEM for QCOM_HIDMA can fix it. And in
drivers/pcmcia/cistpl.c, there are ioremap()/iounmap() calling too.
Make PCMCIA depend on HAS_IOMEM can fix it. 

ioremap_prot() will called outside if CONFIG_HAVE_IOREMAP_PROT is
enabled. With this patchset, it will only be declared and defined when
CONFIG_GENERIC_IOREMAP is enabled. Please correct me if I'm wrong.

Below draft change can fix the compiling errors with the randconfig on
s390 as you suggested. We may need post the driver code change in
another patch since it's not related to this patchset?