From: "David S. Miller" <davem@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: hch@infradead.org, solca@guug.org, zaitcev@redhat.com,
linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
debian-sparc@lists.debian.org
Subject: Re: sparc scsi esp depends on pci & hangs on boot
Date: Tue, 22 Jul 2003 23:57:14 -0700 [thread overview]
Message-ID: <20030722235714.5e2b285d.davem@redhat.com> (raw)
In-Reply-To: <20030723074033.A1687@infradead.org>
On Wed, 23 Jul 2003 07:40:33 +0100
Christoph Hellwig <hch@infradead.org> wrote:
> On Tue, Jul 22, 2003 at 11:29:11PM -0700, David S. Miller wrote:
> > And unlike this particular scsi layer usage, such drivers will be
> > dependant upon things like CONFIG_PCI and thus won't get compiled
> > in unless CONFIG_PCI has been enabled in the kernel configuration.
>
> Umm, no. The whole idea of the DMA mapping API is that it's independant
> of the underlying bus. Think of usb or ieee1394 drivers doing direct DMA
> independant of the bus the underlying host adapter uses.
No USB or IEEE1394 on SBUS sparcs, so again no problem.
My point still holds, please put this enumeration into a truly generic
place that doesn't depend upon the actual implementation.
linux/dma-dir.h or even linux/device.h seem the most logical place (we
put the PCI ones in pci.h, and pci.h can be included cleanly even when
CONFIG_PCI is disabled, consider that), then we make
linux/dma-mapping.h and scsi/scsi_{cmnd,request}.h include this
linux/{device,dma-dir}.h file.
I don't see why this is a problem. Either do this, or fix
asm-generic/dma-mapping.h which is not GENERIC because it
depends upon something SPECIFIC, specifically PCI.
next prev parent reply other threads:[~2003-07-23 6:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-22 2:51 sparc scsi esp depends on pci & hangs on boot Otto Solares
2003-07-22 12:09 ` Pete Zaitcev
2003-07-22 18:26 ` Otto Solares
2003-07-23 0:54 ` David S. Miller
2003-07-23 2:32 ` Otto Solares
2003-07-23 6:07 ` Christoph Hellwig
2003-07-23 6:24 ` David S. Miller
2003-07-23 6:28 ` Christoph Hellwig
2003-07-23 6:29 ` David S. Miller
2003-07-23 6:40 ` Christoph Hellwig
2003-07-23 6:57 ` David S. Miller [this message]
2003-07-23 7:02 ` Christoph Hellwig
2003-07-23 7:20 ` David S. Miller
2003-07-23 8:45 ` Otto Solares
2003-07-23 14:42 ` Geert Uytterhoeven
2003-07-23 6:43 ` Otto Solares
2003-07-23 7:04 ` Christoph Hellwig
2003-07-23 7:20 ` Otto Solares
2003-07-23 7:27 ` David S. Miller
2003-07-23 8:33 ` C.Newport
2003-07-23 8:28 ` David S. Miller
2003-07-23 9:35 ` C.Newport
2003-07-23 9:37 ` David S. Miller
2003-07-23 8:55 ` Otto Solares
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=20030722235714.5e2b285d.davem@redhat.com \
--to=davem@redhat.com \
--cc=debian-sparc@lists.debian.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=solca@guug.org \
--cc=sparclinux@vger.kernel.org \
--cc=zaitcev@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).