On Fri, Sep 03, 2021 at 12:28:41PM +0200, Niklas Schnelle wrote:
> On Fri, 2021-09-03 at 17:40 +0800, Chunyan Zhang wrote:
> > On Fri, 3 Sept 2021 at 16:24, Niklas Schnelle <schnelle@xxxxxxxxxxxxx> wrote:
> > > On Fri, 2021-09-03 at 16:03 +0800, Chunyan Zhang wrote:
> > > > From: Chunyan Zhang <chunyan.zhang@xxxxxxxxxx>
> > > >
> > > > There would not be ioremap and iounmap implementations if CONFIG_PCI is
> > > > not set for s390, so add default declarations of these two functions
> > > > for the case to avoid 'undefined reference' issue.
> > > >
> > > > Fixes: 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions")
> > > > Reported-by: kernel test robot <lkp@xxxxxxxxx>
> > > > Signed-off-by: Chunyan Zhang <chunyan.zhang@xxxxxxxxxx>
> > > > ---
> > > > The issue was reported from https://lkml.org/lkml/2021/8/1/18
...
> > Actually HAS_IOMEM is set as default on other architectures, but not
> > for s390 which redefined it.
>
> Yes because most architectures always have IOMEM and io*map() functions
> I believe. s390 is an exception here as the mainframe native
> functionality all works without MMIO and you can run a fully functional
> system including networking and block devices without any MMIO, PCI and
> without ioremap()/iounmap().
>
> >
> > > At the very least I think the functions should do a WARN_ONCE() but
> > > then we have the same situation as discussed below with Linus making it
> > > pretty clear that he prefers these cases to be compile time checked:
> >
> > Ok, if I understand correctly, if io*map is not implemented for some
> > case, there should be a *compile-time* error rather than adding a stub
> > function to make this kind of errors disappeared.
> >
> > Please correct me if I missed something.
>
> Ideally not a compile time error but a compile time flag such as a
> Kconfig option that would make sure that if HAS_IOMEM isn't set we
> don't get drivers compiled which depend on working io*map(). After all
> these drivers will surely not be functional.
Please note that Arnd Bergmann started to work on that:
https://lkml.org/lkml/2021/7/5/286
However, as far as I can tell, there is nothing like that in
linux-next currently.
Arnd, are you still working on this?
