All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Chunyan Zhang <zhang.lyra@gmail.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	linux-s390@vger.kernel.org, kernel test robot <lkp@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Chunyan Zhang <chunyan.zhang@unisoc.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] s390/io: Fix ioremap and iounmap undefinded issue for s390
Date: Fri, 03 Sep 2021 12:28:41 +0200	[thread overview]
Message-ID: <9e4780da8c899f2272923cc4fe72814891845226.camel@linux.ibm.com> (raw)
In-Reply-To: <CAAfSe-v0DbOS5p7nF0db4SdTrsy28gJNdW93ds4capVxuUO1xw@mail.gmail.com>

On Fri, 2021-09-03 at 17:40 +0800, Chunyan Zhang wrote:
> On Fri, 3 Sept 2021 at 16:24, Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > On Fri, 2021-09-03 at 16:03 +0800, Chunyan Zhang wrote:
> > > From: Chunyan Zhang <chunyan.zhang@unisoc.com>
> > > 
> > > 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@intel.com>
> > > Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
> > > ---
> > > The issue was reported from https://lkml.org/lkml/2021/8/1/18
> > 
> > Thanks for the patch but I'm a little skeptical about adding
> > ioremap()/iounmap() stubs that don't do anything useful and on top ofn
> > that would do so silently.
> > 
> > In the above discussion you said that TIMER_OF should depend on
> > HAS_IOMEM. In arch/s390/Kconfig HAS_IOMEM is set if and only if
> > CONFIG_PCI is set so that sounds to me like it would prevent the
> > undefined reference without the risk of someone trying to use io*map()
> > without CONFIG_PCI.
> 
> Humm... you can ignore my reply on that time, I later found that's not
> correct :)
> 
> TIMER_OF would be selected by other configs and it seems not able to
> depends on HAS_IOMEM, unless all configs which select TIMER_OF depend
> on HAS_IOMEM, that would be a big change.

Hmm I already see a lot of the options in drivers/clocksource/Kconfig
depend on HAS_IOMEM and drivers/clocksource/timer-of.c definitely calls
iounmap() so wouldn't that be the logical change even if it is bigger? 

> 
> 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.

> 
> Thanks,
> Chunyan
> 
> > https://lkml.org/lkml/2021/7/2/511
> > 
> > 
> > > ---
> > >  arch/s390/include/asm/io.h | 15 ++++++++++++---
> > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/arch/s390/include/asm/io.h b/arch/s390/include/asm/io.h
> > > index e3882b012bfa..9438370c6445 100644
> > > --- a/arch/s390/include/asm/io.h
> > > +++ b/arch/s390/include/asm/io.h
> > > @@ -23,11 +23,8 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr);
> > >  #define IO_SPACE_LIMIT 0
> > > 
> > > 
> > .. snip ..
> > 


  reply	other threads:[~2021-09-03 10:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03  7:56 [PATCH] s390/io: Fix ioremap and iounmap undefinded issue for s390 Chunyan Zhang
2021-09-03  8:03 ` Chunyan Zhang
2021-09-03  8:24   ` Niklas Schnelle
2021-09-03  9:40     ` Chunyan Zhang
2021-09-03 10:28       ` Niklas Schnelle [this message]
2021-09-03 10:51         ` Heiko Carstens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e4780da8c899f2272923cc4fe72814891845226.camel@linux.ibm.com \
    --to=schnelle@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=chunyan.zhang@unisoc.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=tglx@linutronix.de \
    --cc=zhang.lyra@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.