All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: John Whitney <johnw@sands-edge.com>
Cc: linuxppc-dev list <linuxppc-dev@lists.linuxppc.org>
Subject: Re: Proposed changes to io.h
Date: Sat, 03 Apr 2004 13:04:24 +1000	[thread overview]
Message-ID: <1080961463.1426.82.camel@gaston> (raw)
In-Reply-To: <43B0E668-84BC-11D8-9FF0-000A95A07384@sands-edge.com>


On Sat, 2004-04-03 at 01:41, John Whitney wrote:
> > No, you are not supposed to pass an address coming from
> > pci_alloc_consistent() to pci_map_single(), period.
> >
>
> Why take that stance, when a simple change to virt_to_phys() makes all
> virtual addresses coming from any routine work correctly?  Would that
> be far simpler system under which to implement code, with less prone to
> error (no need to worry about making sure you have the "correct"
> virtual memory type for a given routine - all virtual memory addresses
> would work).  This just sounds entirely political, and very little
> practical.

No. virt_to_phys() operates on the linear mapping only, that has
always been the case, doing otherwise would be non portable anyway.

I think we should deprecate virt_to_phys() anyway and use __pa in
the arch code, that would avoid people trying to use it for what it
is not.

Regarding pci_map_single(), it's semantics are clear regarding the
kind of memory it can map. Doing a ppc only hack to make the nonsense
work (passing it memory obtained by pci_alloc_consistent) would be
letting drivers writers do the wrong thing on ppc and break whenever
they port the driver to a platform that enforce that limitation.

We could add a runtime check to pci_map_single() to verify it gets
passed an address within the linear mapping though. That would catch
the bugs you are afraid of.

(Oh, and let's keep those discussions on-list).

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  parent reply	other threads:[~2004-04-03  3:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-31 15:44 Proposed changes to io.h John Whitney
2004-03-31 16:44 ` Eugene Surovegin
2004-03-31 16:58   ` Dan Malek
2004-03-31 17:30     ` Matt Porter
2004-03-31 17:32     ` John Whitney
2004-03-31 17:40       ` Dan Malek
2004-03-31 17:03   ` Matt Porter
2004-03-31 19:57     ` John Whitney
2004-03-31 22:07       ` Matt Porter
2004-03-31 22:25         ` John Whitney
2004-03-31 22:52         ` Dan Malek
2004-04-01  5:30           ` Kumar Gala
2004-03-31 17:01 ` Matt Porter
2004-03-31 17:29   ` Dan Malek
2004-03-31 18:18 ` Christoph Hellwig
2004-03-31 18:40   ` John Whitney
2004-03-31 18:43     ` Christoph Hellwig
2004-03-31 18:50       ` John Whitney
2004-03-31 21:09   ` John Whitney
2004-03-31 21:49     ` Dan Malek
2004-03-31 21:52     ` Eugene Surovegin
2004-03-31 22:07       ` John Whitney
2004-04-01  2:52 ` Benjamin Herrenschmidt
     [not found]   ` <209F76E4-838B-11D8-9FF0-000A95A07384@sands-edge.com>
     [not found]     ` <1080790433.1433.59.camel@gaston>
     [not found]       ` <43B0E668-84BC-11D8-9FF0-000A95A07384@sands-edge.com>
2004-04-03  3:04         ` Benjamin Herrenschmidt [this message]
2004-04-03  3:40           ` John Whitney

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=1080961463.1426.82.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=johnw@sands-edge.com \
    --cc=linuxppc-dev@lists.linuxppc.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.