From: Grant Grundler <iod00d@hp.com> To: Colin Ngam <cngam@sgi.com> Cc: Grant Grundler <iod00d@hp.com>, Patrick Gefre <pfg@sgi.com>, "Luck, Tony" <tony.luck@intel.com>, Matthew Wilcox <matthew@wil.cx>, Jesse Barnes <jbarnes@engr.sgi.com>, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org Subject: Re: [PATCH] 2.6 SGI Altix I/O code reorganization Date: Wed, 6 Oct 2004 12:54:24 -0700 [thread overview] Message-ID: <20041006195424.GF25773@cup.hp.com> (raw) In-Reply-To: <41644301.9EC028B3@sgi.com> Colin, thanks for ACKing the feedback. I think there is still some confusion... On Wed, Oct 06, 2004 at 02:09:54PM -0500, Colin Ngam wrote: ... > > Mathew explained replacing the raw_pci_ops pointer is the Right Thing > > and I suspect it's easier to properly implement. > > I believe we did just that. We did not touch pci_root_ops. Correct. The patch ignores/overides pci_root_ops with sn_pci_root_ops (which is what I originally suggested). Mathew's point was only raw_pci_ops needs to point at a different set of struct pci_raw_ops (see include/linux/pci.h). > > I realize that's not easy to add/maintain in the arch/ia64 port though > > since pcibios_fixup_bus() is common code for multiple platforms. > > Yes, would anybody allow us to make a platform specific callout > from within generic pcibios_fixup_bus()??? If it can be avoided, preferably not. But that's up to Jesse/Tony I think. ... > > It means we are telling PCI subsystem to walk root busses that don't > > exist in all configurations. I hope there are no nasty side effects > > from that. > > Not at all. If you look at the loop, sn_pci_fixup_bus(0 gets called for 0 - > PCI_BUSES_TO_SCAN but if the bus does not exist, Can you quote the bit of the patch which implements "if the bus does not exist" check? I can't find it. > One favour. Would you agree to letting this patch be included by Tony > and we will come up with another patch to fix the 2 obvious items listed > above? It will be great to avoid spinning this big patch. I think that's up to Jesse/Tony. I don't "own" any of the code in question. Just trying to undo the confusion I caused. grant
WARNING: multiple messages have this Message-ID (diff)
From: Grant Grundler <iod00d@hp.com> To: Colin Ngam <cngam@sgi.com> Cc: Grant Grundler <iod00d@hp.com>, Patrick Gefre <pfg@sgi.com>, "Luck, Tony" <tony.luck@intel.com>, Matthew Wilcox <matthew@wil.cx>, Jesse Barnes <jbarnes@engr.sgi.com>, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org Subject: Re: [PATCH] 2.6 SGI Altix I/O code reorganization Date: Wed, 06 Oct 2004 19:54:24 +0000 [thread overview] Message-ID: <20041006195424.GF25773@cup.hp.com> (raw) In-Reply-To: <41644301.9EC028B3@sgi.com> Colin, thanks for ACKing the feedback. I think there is still some confusion... On Wed, Oct 06, 2004 at 02:09:54PM -0500, Colin Ngam wrote: ... > > Mathew explained replacing the raw_pci_ops pointer is the Right Thing > > and I suspect it's easier to properly implement. > > I believe we did just that. We did not touch pci_root_ops. Correct. The patch ignores/overides pci_root_ops with sn_pci_root_ops (which is what I originally suggested). Mathew's point was only raw_pci_ops needs to point at a different set of struct pci_raw_ops (see include/linux/pci.h). > > I realize that's not easy to add/maintain in the arch/ia64 port though > > since pcibios_fixup_bus() is common code for multiple platforms. > > Yes, would anybody allow us to make a platform specific callout > from within generic pcibios_fixup_bus()??? If it can be avoided, preferably not. But that's up to Jesse/Tony I think. ... > > It means we are telling PCI subsystem to walk root busses that don't > > exist in all configurations. I hope there are no nasty side effects > > from that. > > Not at all. If you look at the loop, sn_pci_fixup_bus(0 gets called for 0 - > PCI_BUSES_TO_SCAN but if the bus does not exist, Can you quote the bit of the patch which implements "if the bus does not exist" check? I can't find it. > One favour. Would you agree to letting this patch be included by Tony > and we will come up with another patch to fix the 2 obvious items listed > above? It will be great to avoid spinning this big patch. I think that's up to Jesse/Tony. I don't "own" any of the code in question. Just trying to undo the confusion I caused. grant
next prev parent reply other threads:[~2004-10-06 19:59 UTC|newest] Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-10-05 20:34 [PATCH] 2.6 SGI Altix I/O code reorganization Luck, Tony 2004-10-05 20:34 ` Luck, Tony 2004-10-06 15:32 ` Patrick Gefre 2004-10-06 15:32 ` Patrick Gefre 2004-10-06 18:57 ` Grant Grundler 2004-10-06 18:57 ` Grant Grundler 2004-10-06 19:09 ` Colin Ngam 2004-10-06 19:09 ` Colin Ngam 2004-10-06 19:54 ` Grant Grundler [this message] 2004-10-06 19:54 ` Grant Grundler 2004-10-06 19:54 ` Colin Ngam 2004-10-06 19:54 ` Colin Ngam 2004-10-06 20:10 ` Patrick Gefre 2004-10-06 20:10 ` Patrick Gefre 2004-10-06 20:44 ` Jesse Barnes 2004-10-06 20:44 ` Jesse Barnes 2004-10-07 15:02 ` Patrick Gefre 2004-10-07 15:02 ` Patrick Gefre 2004-10-07 16:52 ` Jesse Barnes 2004-10-07 16:52 ` Jesse Barnes 2004-10-06 20:27 ` Jesse Barnes 2004-10-06 20:27 ` Jesse Barnes 2004-10-06 20:21 ` Colin Ngam 2004-10-06 20:21 ` Colin Ngam 2004-10-06 20:33 ` Matthew Wilcox 2004-10-06 20:33 ` Matthew Wilcox 2004-10-06 20:48 ` Grant Grundler 2004-10-06 20:48 ` Grant Grundler 2004-10-06 21:05 ` Matthew Wilcox 2004-10-06 21:05 ` Matthew Wilcox 2004-10-06 20:55 ` Colin Ngam 2004-10-06 20:55 ` Colin Ngam 2004-10-08 15:16 ` Colin Ngam 2004-10-08 15:16 ` Colin Ngam 2004-10-08 16:37 ` Jesse Barnes 2004-10-08 16:37 ` Jesse Barnes 2004-10-09 22:20 ` Grant Grundler 2004-10-09 22:20 ` Grant Grundler [not found] ` <4169A508.84FB19C7@sgi.com> 2004-10-11 14:03 ` Patrick Gefre 2004-10-11 14:03 ` Patrick Gefre 2004-10-08 22:37 ` Colin Ngam 2004-10-08 22:37 ` Colin Ngam -- strict thread matches above, loose matches on Subject: below -- 2004-10-11 20:49 Luck, Tony 2004-10-11 20:49 ` Luck, Tony 2004-10-07 17:06 Luck, Tony 2004-10-07 17:06 ` Luck, Tony 2004-10-07 17:22 ` Jesse Barnes 2004-10-07 17:22 ` Jesse Barnes 2004-10-07 18:59 ` Jes Sorensen 2004-10-07 18:59 ` Jes Sorensen 2004-10-05 19:16 Luck, Tony 2004-10-05 19:16 ` Luck, Tony 2004-10-05 19:35 ` Patrick Gefre 2004-10-05 19:35 ` Patrick Gefre 2004-10-05 5:13 Luck, Tony 2004-10-05 5:13 ` Luck, Tony 2004-10-05 15:43 ` Jesse Barnes 2004-10-05 15:43 ` Jesse Barnes 2004-10-05 16:22 ` Grant Grundler 2004-10-05 16:22 ` Grant Grundler 2004-10-05 17:45 ` Matthew Wilcox 2004-10-05 17:45 ` Matthew Wilcox 2004-10-05 19:00 ` Colin Ngam 2004-10-05 19:00 ` Colin Ngam 2004-10-05 19:10 ` Grant Grundler 2004-10-05 19:10 ` Grant Grundler 2004-10-05 19:15 ` Matthew Wilcox 2004-10-05 19:15 ` Matthew Wilcox 2004-10-05 18:20 ` Patrick Gefre 2004-10-05 18:20 ` Patrick Gefre 2004-10-05 18:34 ` Jesse Barnes 2004-10-05 18:34 ` Jesse Barnes 2004-10-04 21:57 Pat Gefre 2004-10-04 21:57 ` Pat Gefre 2004-10-05 15:48 ` Christoph Hellwig 2004-10-05 15:48 ` Christoph Hellwig 2004-10-05 18:26 ` Patrick Gefre 2004-10-05 18:26 ` Patrick Gefre 2004-10-05 23:30 ` Patrick Gefre 2004-10-05 23:30 ` Patrick Gefre 2004-10-05 15:50 ` Christoph Hellwig 2004-10-05 15:50 ` Christoph Hellwig
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=20041006195424.GF25773@cup.hp.com \ --to=iod00d@hp.com \ --cc=cngam@sgi.com \ --cc=jbarnes@engr.sgi.com \ --cc=linux-ia64@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=matthew@wil.cx \ --cc=pfg@sgi.com \ --cc=tony.luck@intel.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: linkBe 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.