From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: linux-input@atrey.karlin.mff.cuni.cz,
Linux Kernel list <linux-kernel@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Paul Mackerras <paulus@samba.org>,
Anton Blanchard <anton@samba.org>, Greg KH <greg@kroah.com>
Subject: Re: DMA APIs gumble grumble
Date: Wed, 08 Nov 2006 21:00:33 +1100 [thread overview]
Message-ID: <1162980033.28571.732.camel@localhost.localdomain> (raw)
In-Reply-To: <20061108092150.GB3405@rhun.haifa.ibm.com>
On Wed, 2006-11-08 at 11:21 +0200, Muli Ben-Yehuda wrote:
> On Wed, Nov 08, 2006 at 07:47:33PM +1100, Benjamin Herrenschmidt wrote:
>
> > I agree, though, device_ext sucks as a name, you are welcome to propose
> > something better, I'm no good at finding names :-)
>
> Seems a lot like `pci_sysdata' on x86-64 and i386 with Jeff's PCI
> domains support. dev_sysdata? naming is not my strong suit :-)
>
> struct pci_sysdata {
> int domain; /* PCI domain */
> int node; /* NUMA node */
> void* iommu; /* IOMMU private data */
> };
Interesting... It looks a _lot_ like my device_ext :-)
The reason we don't use PCI sysdata is that currently, our PCI layer
already hijacks it with something else (ugh, I know, it sucks). I'm
pondering consolidating all of this though, but since I need that for
more than PCI, it cannot be just sysdata. Also, as I explained, I'd
prefer having it directly in struct device to avoid one more pointer
indirection in the DMA hot path.
But it looks like if we get that, x86 might be able to move their
sysdata to there.
You might be bad at naming, but I'm worse. Your dev_sysdata wins over my
device_ext imho :-)
So unless I get some better proposal, I'll do a patch introducing that
as an empty struct on all archs, possibly tonmorrow, and then start
migrating things to it.
Cheers,
Ben.
next prev parent reply other threads:[~2006-11-08 10:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-08 1:54 DMA APIs gumble grumble Benjamin Herrenschmidt
2006-11-08 4:46 ` David Miller
2006-11-08 5:23 ` Benjamin Herrenschmidt
2006-11-08 5:29 ` David Miller
2006-11-08 5:44 ` Benjamin Herrenschmidt
2006-11-10 1:02 ` Benjamin Herrenschmidt
2006-11-10 2:50 ` David Miller
2006-11-10 2:55 ` Benjamin Herrenschmidt
2006-11-10 3:01 ` David Miller
2006-11-10 4:07 ` Benjamin Herrenschmidt
2006-11-08 8:25 ` Muli Ben-Yehuda
2006-11-08 8:47 ` Benjamin Herrenschmidt
2006-11-08 9:21 ` Muli Ben-Yehuda
2006-11-08 10:00 ` Benjamin Herrenschmidt [this message]
2006-11-08 22:56 ` Russell King
2006-11-08 23:41 ` Benjamin Herrenschmidt
2006-11-09 0:43 ` Benjamin Herrenschmidt
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=1162980033.28571.732.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=anton@samba.org \
--cc=davem@davemloft.net \
--cc=greg@kroah.com \
--cc=linux-input@atrey.karlin.mff.cuni.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=muli@il.ibm.com \
--cc=paulus@samba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox