From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Brian King <brking@us.ibm.com>,
Linux Arch list <linux-arch@vger.kernel.org>,
Matthew Wilcox <matthew@wil.cx>, Greg KH <greg@kroah.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc64-dev <linuxppc64-dev@ozlabs.org>,
linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: pci: Arch hook to determine config space size
Date: Thu, 03 Feb 2005 11:23:35 +1100 [thread overview]
Message-ID: <1107390215.30709.88.camel@gaston> (raw)
In-Reply-To: <200502021105.42249.arnd@arndb.de>
On Wed, 2005-02-02 at 11:05 +0100, Arnd Bergmann wrote:
> How about something along the lines of this patch? Instead of adding a
> pointer to the pci data from the device node, it embeds the node inside
> a new struct pci_device_node. The patch is not complete and therefore
> not expected to work as is, but maybe you want to reuse it.
>
> The interesting part that is missing is creating and destroying
> pci_device_nodes in prom.c, maybe you have an idea how to do that.
>
> I'm also not sure about eeh. Are the eeh functions known to be called
> only for device_nodes of PCI devices? If not, eeh_mode and
> eeh_config_addr might have to stay inside of device_node.
I'd rather not go that way for now. There are at least PCI and VIO
devices concerned by this, and maybe more (depending on how I deal
with macio devices for example). We also want, ultimately, to have
the DMA routines be function pointers in this auxilliary structure.
Ben.
next prev parent reply other threads:[~2005-02-03 0:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-28 14:56 [PATCH 1/2] pci: Arch hook to determine config space size brking
2005-01-28 18:52 ` Christoph Hellwig
2005-01-29 4:06 ` Greg KH
2005-01-31 19:10 ` Brian King
2005-01-31 19:15 ` Greg KH
2005-01-31 19:29 ` Matthew Wilcox
2005-01-31 20:51 ` Arnd Bergmann
2005-01-31 21:35 ` Brian King
2005-01-31 21:56 ` Arnd Bergmann
2005-01-31 22:13 ` Greg KH
2005-01-31 22:43 ` Brian King
2005-02-01 3:15 ` Benjamin Herrenschmidt
2005-02-01 4:52 ` Brian King
2005-02-01 4:57 ` Benjamin Herrenschmidt
2005-02-02 10:05 ` Arnd Bergmann
2005-02-03 0:23 ` Benjamin Herrenschmidt [this message]
2005-02-01 12:32 ` Matthew Wilcox
2005-02-01 20:16 ` Brian King
2005-01-31 19:40 ` Brian King
2005-02-01 7:46 ` Grant Grundler
2005-02-01 15:23 ` Brian King
-- strict thread matches above, loose matches on Subject: below --
2005-01-31 23:22 arndb
2005-01-31 23:22 ` arndb
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=1107390215.30709.88.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=arnd@arndb.de \
--cc=brking@us.ibm.com \
--cc=greg@kroah.com \
--cc=hch@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=linuxppc64-dev@ozlabs.org \
--cc=matthew@wil.cx \
--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 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.