From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Luis R. Rodriguez" <mcgrof@suse.com>,
"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
linux-arch@vger.kernel.org, mingo@kernel.org,
heiko.carstens@de.ibm.com, linux-s390@vger.kernel.org,
bp@suse.de, linux@roeck-us.net, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, rostedt@goodmis.org
Subject: Re: [RFC] asm-generic/pci_iomap.h: make custom PCI BAR requirements explicit
Date: Fri, 11 Sep 2015 10:14:09 +0200 [thread overview]
Message-ID: <20150911101409.79a7b3ef@mschwide> (raw)
In-Reply-To: <1866509.8pE0MIz57e@wuerfel>
On Tue, 08 Sep 2015 15:42:40 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 03 September 2015 03:44:15 Luis R. Rodriguez wrote:
> > On Sun, Aug 30, 2015 at 09:30:26PM +0200, Arnd Bergmann wrote:
> > > On Friday 28 August 2015 17:17:27 Luis R. Rodriguez wrote:
> > > > While at it, as with the ioremap*() variants, since we have no clear
> > > > semantics yet well defined provide a solution for them that returns
> > > > NULL. This allows architectures to move forward by defining pci_ioremap*()
> > > > variants without requiring immediate changes to all architectures. Each
> > > > architecture then can implement their own solution as needed and
> > > > when they get to it.
> > >
> > > Which architectures are you thinking about here?
> >
> > Really only S390 would benefit from this now.
>
> Ok
>
> > > > Build tested with allyesconfig on:
> > > >
> > > > * S390
> > > > * x86_64
> > > >
> > > > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> > >
> > > It's not really clear to me what the purpose of the patch is, is this
> > > meant as a cleanup, or are you trying to avoid some real-life bugs
> > > you ran into?
> >
> > Upon adding a new helper into CONFIG_PCI_IOMAP it was only through
> > 0-day build testing that I found that I needed to add something for S390.
> > This means we fix S390 reactively. With the asm-generic stuff in place
> > to return NULL we don't need to do anything but a respective return
> > NULL static inline, the moment that is done the author would know some
> > architectures may not get support for the functionality they are adding.
> > Without this we only find out reactively.
>
> Hmm, my gut feeling tells me that your approach won't solve the problem
> in general. s390 PCI is just weird in many ways and it will occasionally
> suffer from problems like this (as do other aspects of the s390 architecture
> that are unlike the rest of the world).
>
> Maybe Martin and Heiko can comment on this, they may have a preference
> from the s390 point of view.
I do not see how the additional Kconfig ARCH_PCI_NON_DISJUNCTIVE and the
#ifdef indirections help with anything. An extension to lib/pci_iomap.c
now requires an extra inline function in include/asm-generic/pci_iomap.h
which I am sure will be added blindly without any consideration what
s390 needs.
Actually the patch makes it worse as the new inline will cover things up.
Instead of a zero day compile error we will be left with a silently broken
extension.
I prefer a compile error as it points out that there is a problem.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2015-09-11 8:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-29 0:17 [RFC] asm-generic/pci_iomap.h: make custom PCI BAR requirements explicit Luis R. Rodriguez
2015-08-29 2:13 ` Randy Dunlap
2015-10-02 23:17 ` Luis R. Rodriguez
2015-10-04 0:14 ` Randy Dunlap
2015-10-05 16:58 ` Luis R. Rodriguez
2015-08-29 15:25 ` Christoph Hellwig
2015-09-03 1:45 ` Luis R. Rodriguez
2015-08-30 19:30 ` Arnd Bergmann
2015-09-03 1:44 ` Luis R. Rodriguez
2015-09-03 1:47 ` Luis R. Rodriguez
2015-09-08 9:54 ` Luis R. Rodriguez
2015-09-08 13:42 ` Arnd Bergmann
2015-09-11 8:14 ` Martin Schwidefsky [this message]
2015-10-03 0:04 ` Luis R. Rodriguez
2015-10-02 23:53 ` Luis R. Rodriguez
2015-10-04 19:02 ` Arnd Bergmann
2015-10-05 17:09 ` Luis R. Rodriguez
2015-10-06 11:15 ` Martin Schwidefsky
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=20150911101409.79a7b3ef@mschwide \
--to=schwidefsky@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bp@suse.de \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mcgrof@do-not-panic.com \
--cc=mcgrof@suse.com \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.org \
/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.