All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Christoph Hellwig <hch@infradead.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Jeff Garzik <jgarzik@pobox.com>, Tejun Heo <htejun@gmail.com>,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [patch] linux/io.h: forward declare struct pci_dev
Date: Sun, 11 Feb 2007 01:26:40 -0500	[thread overview]
Message-ID: <45CEB720.1020406@gmail.com> (raw)
In-Reply-To: <20070211034902.GA9077@infradead.org>

Christoph Hellwig wrote:
> I haven't looked at what causes it, but any leakage of pci details
> into io.h is bogus.  I'd suggest that the original submitter fixes
> up that problem instead.

pci_iomap() depends on two things - PCI and iomap.  AFAIK, there is no 
config to test whether the current arch supports iomap or not. 
Previously it worked because those archs which don't support either one 
doesn't have set CONFIG_GENERIC_IOMAP while not implementing 
arch-specific ones && not compiling any driver which uses the iomap 
interface.  This is why pci_iomap() ended up in lib/iomap.c in the first 
place; otherwise, it cannot be conditionalized correctly as devers 
currently shows (the 'not implementing arch-specific ones' part cannot 
be easily tested).

So, it seems what we need is either 1. bogus iomap implementation for 
all archs or 2. CONFIG_IOMAP.  Hmmm... I think CONFIG_IOMAP is better as 
it will allow leaving out related devres parts (or any generic function 
using iomap).

-- 
tejun

  reply	other threads:[~2007-02-11  6:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-10 11:45 [patch] linux/io.h: forward declare struct pci_dev Heiko Carstens
2007-02-11  3:49 ` Christoph Hellwig
2007-02-11  6:26   ` Tejun Heo [this message]
2007-02-11  6:34     ` Al Viro
2007-02-11  6:46       ` Tejun Heo
2007-02-11  6:55       ` Randy Dunlap
2007-02-11  7:10       ` Christoph Hellwig
2007-02-11  8:21         ` Al Viro
2007-02-11 15:09       ` Jeff Garzik
2007-02-11 15:31       ` Heiko Carstens
2007-02-11 15:41         ` [PATCH] sort the devres mess out Al Viro
2007-02-11 15:49           ` Jeff Garzik
2007-02-11 22:16             ` Roland Dreier
2007-02-12  5:30               ` [PATCH] ia64: Fix noncoherent DMA API so devres builds Roland Dreier
2007-02-12 21:06                 ` Luck, Tony

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=45CEB720.1020406@gmail.com \
    --to=htejun@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --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.