All of lore.kernel.org
 help / color / mirror / Atom feed
From: Colin Ngam <cngam@sgi.com>
To: Grant Grundler <iod00d@hp.com>
Cc: 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:09 +0000	[thread overview]
Message-ID: <41644D61.9A75D7E7@sgi.com> (raw)
In-Reply-To: 20041006195424.GF25773@cup.hp.com

Grant Grundler wrote:

> 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).

Hi Grant,

Well, I am confused then.

Originally, we needed to use pci_root_ops in io_init.c to pass it to
pci_scan_bus().  But pci_root_ops is defined as a static in pci/pci.c.  We took
out the static so that we can use this in io_init.c.  However, it sounded like
you guys do not want to externalize pci_root_ops.  Okay, we created
sn_pci_root_ops.

We do not want pci_raw_ops to point at anything different.  It is exactly what we
needed now that we have implemented in our Prom all the pci config read/write SAL
calls.

>
>
> > >   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.

In the routine sn_pci_fixup_bus()

+static void sn_pci_fixup_bus(int segment, int busnum)
+{
+       int status = 0;
+       int nasid, cnode;
+       struct pci_bus *bus;
+       struct pci_controller *controller;
+       struct pcibus_bussoft *prom_bussoft_ptr;
+       struct hubdev_info *hubdev_info;
+       void *provider_soft;
+
+       status +           sal_get_pcibus_info((u64) segment, (u64) busnum,
+                               (u64) ia64_tpa(&prom_bussoft_ptr));
+       if (status > 0) {
+               return;         /* bus # does not exist */
+       }
+
+       prom_bussoft_ptr = __va(prom_bussoft_ptr);
+       controller = sn_alloc_pci_sysdata();
+       if (!controller) {
+               BUG();
+       }
+
+       bus = pci_scan_bus(busnum, &sn_pci_root_ops, controller);
+       if (bus = NULL) {
+               return;         /* error, or bus already scanned */
+       }

We bail if sal_get_pcibus_info() is not successful.  Am I missing something?

>
>
> > 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.

Thanks.

colin

>
>
> grant


WARNING: multiple messages have this Message-ID (diff)
From: Colin Ngam <cngam@sgi.com>
To: Grant Grundler <iod00d@hp.com>
Cc: 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 14:54:09 -0500	[thread overview]
Message-ID: <41644D61.9A75D7E7@sgi.com> (raw)
In-Reply-To: 20041006195424.GF25773@cup.hp.com

Grant Grundler wrote:

> 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).

Hi Grant,

Well, I am confused then.

Originally, we needed to use pci_root_ops in io_init.c to pass it to
pci_scan_bus().  But pci_root_ops is defined as a static in pci/pci.c.  We took
out the static so that we can use this in io_init.c.  However, it sounded like
you guys do not want to externalize pci_root_ops.  Okay, we created
sn_pci_root_ops.

We do not want pci_raw_ops to point at anything different.  It is exactly what we
needed now that we have implemented in our Prom all the pci config read/write SAL
calls.

>
>
> > >   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.

In the routine sn_pci_fixup_bus()

+static void sn_pci_fixup_bus(int segment, int busnum)
+{
+       int status = 0;
+       int nasid, cnode;
+       struct pci_bus *bus;
+       struct pci_controller *controller;
+       struct pcibus_bussoft *prom_bussoft_ptr;
+       struct hubdev_info *hubdev_info;
+       void *provider_soft;
+
+       status =
+           sal_get_pcibus_info((u64) segment, (u64) busnum,
+                               (u64) ia64_tpa(&prom_bussoft_ptr));
+       if (status > 0) {
+               return;         /* bus # does not exist */
+       }
+
+       prom_bussoft_ptr = __va(prom_bussoft_ptr);
+       controller = sn_alloc_pci_sysdata();
+       if (!controller) {
+               BUG();
+       }
+
+       bus = pci_scan_bus(busnum, &sn_pci_root_ops, controller);
+       if (bus == NULL) {
+               return;         /* error, or bus already scanned */
+       }

We bail if sal_get_pcibus_info() is not successful.  Am I missing something?

>
>
> > 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.

Thanks.

colin

>
>
> grant


  reply	other threads:[~2004-10-06 19:54 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-04 21:57 [PATCH] 2.6 SGI Altix I/O code reorganization Pat Gefre
2004-10-04 21:57 ` Pat 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-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
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 20:34 ` 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
2004-10-06 19:54           ` Grant Grundler
2004-10-06 19:54           ` Colin Ngam [this message]
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
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-11 20:49 ` Luck, Tony
2004-10-11 20:49   ` Luck, Tony

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=41644D61.9A75D7E7@sgi.com \
    --to=cngam@sgi.com \
    --cc=iod00d@hp.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: 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.