From: Rolf Eike Beer <eike-kernel@sf-tec.de>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-arch@vger.kernel.org,
Parisc List <linux-parisc@vger.kernel.org>
Subject: Re: [PATCH] fix compile break caused by iomap: make IOPORT/PCI mapping functions conditional
Date: Mon, 30 Jan 2012 21:10:45 +0100 [thread overview]
Message-ID: <1539148.qFWsuy2OOI@eto> (raw)
In-Reply-To: <1327941647.21193.53.camel@dabdike.int.hansenpartnership.com>
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
Am Montag 30 Januar 2012, 10:40:47 schrieb James Bottomley:
> The problem in
>
> commit fea80311a939a746533a6d7e7c3183729d6a3faf
> Author: Randy Dunlap <rdunlap@xenotime.net>
> Date: Sun Jul 24 11:39:14 2011 -0700
>
> iomap: make IOPORT/PCI mapping functions conditional
>
>
> is that if your architecture supplies pci_iomap/pci_iounmap, it expects
> always to supply them. Adding empty body defitions in the !CONFIG_PCI
> case, which is what this patch does, breaks the parisc compile because
> the functions become doubly defined. It took us a while to spot this,
> because we don't actually build !CONFIG_PCI very often (only if someone
> is brave enough to test the snake/asp machines).
>
> Since the note in the commit log says this is to fix a
> CONFIG_GENERIC_IOMAP issue (which it does because CONFIG_GENERIC_IOMAP
> supplies pci_iounmap only if CONFIG_PCI is set), there should actually
> have been a condition upon this. This should make sure no other
> architecture's !CONFIG_PCI compile breaks in the same way as parisc.
>
> The fix had to be updated to take account of the GENERIC_PCI_IOMAP
> separation.
So this means we end up still building the PA-RISC PCI code even if the config
says no PCI. That doesn't really sound consistent to me. I really would have
expected that we do not build any non-void PCI code then.
> Reported-by: Rolf Eike Beer <eike@sf-mail.de>
I used the wrong email account when sending out the last patch where you took
that from, please change that to the address used in this mail.
Eike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2012-01-30 20:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-30 16:40 [PATCH] fix compile break caused by iomap: make IOPORT/PCI mapping functions conditional James Bottomley
2012-01-30 20:10 ` Rolf Eike Beer [this message]
2012-01-30 22:45 ` James Bottomley
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=1539148.qFWsuy2OOI@eto \
--to=eike-kernel@sf-tec.de \
--cc=James.Bottomley@hansenpartnership.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=rdunlap@xenotime.net \
--cc=torvalds@linux-foundation.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.