All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <iod00d@hp.com>
To: Patrick Gefre <pfg@sgi.com>
Cc: "Luck, Tony" <tony.luck@intel.com>,
	cngam@sgi.com, Matthew Wilcox <matthew@wil.cx>,
	Grant Grundler <iod00d@hp.com>,
	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 11:57:39 -0700	[thread overview]
Message-ID: <20041006185739.GA25773@cup.hp.com> (raw)
In-Reply-To: <41641007.5020702@sgi.com>

On Wed, Oct 06, 2004 at 10:32:23AM -0500, Patrick Gefre wrote:
> o added our own pci_ops (Grant/Matthew's request)

Sorry - my bad.
I confused the issue by claiming one should replace pci_root_ops.
It was one possibility but it's not an easy path to take.

Mathew explained replacing the raw_pci_ops pointer is the Right Thing
and I suspect it's easier to properly implement.

Some comments on the implementation:
o sn_pci_fixup_bus() is a confusing name. "pcibios_fixup_bus" is normally
  called by generic PCI code after each bus is walked.
  This code obviously doesn't support that.
  Maybe, sn_init_pci_controller() or something like that would be clearer.

o This bit of code belongs in the pcibios_fixup_bus() call path:
	+       /*
	+        * Generic Linux PCI Layer has created the pci_bus and pci_dev
	+        * structures - time for us to add our SN PLatform specific
	+        * information.
	+        */
	+
	+       while ((pci_dev =
	+               pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pci_dev)) != NULL) {
	+               sn_pci_fixup_slot(pci_dev);
	+       }

  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.

o sn_pci_fixup_bus() should be called for each PCI root bus controller
  the firmware advertises. The loop in sn_pci_init() is hard coded
  to loop from 0 to 256 busses.
  Is ACPI the only way PCI host controllers are advertised?
  SN2 doesn't use a different method today?

  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.

o the BUG() in:

  	+       controller = sn_alloc_pci_sysdata();
	+       if (!controller) {
	+               BUG();
	+       }
  is redundant with the BUG in sn_alloc_pci_sysdata().

sorry for the initial bad advice and I hope this helps,
grant

WARNING: multiple messages have this Message-ID (diff)
From: Grant Grundler <iod00d@hp.com>
To: Patrick Gefre <pfg@sgi.com>
Cc: "Luck, Tony" <tony.luck@intel.com>,
	cngam@sgi.com, Matthew Wilcox <matthew@wil.cx>,
	Grant Grundler <iod00d@hp.com>,
	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 18:57:39 +0000	[thread overview]
Message-ID: <20041006185739.GA25773@cup.hp.com> (raw)
In-Reply-To: <41641007.5020702@sgi.com>

On Wed, Oct 06, 2004 at 10:32:23AM -0500, Patrick Gefre wrote:
> o added our own pci_ops (Grant/Matthew's request)

Sorry - my bad.
I confused the issue by claiming one should replace pci_root_ops.
It was one possibility but it's not an easy path to take.

Mathew explained replacing the raw_pci_ops pointer is the Right Thing
and I suspect it's easier to properly implement.

Some comments on the implementation:
o sn_pci_fixup_bus() is a confusing name. "pcibios_fixup_bus" is normally
  called by generic PCI code after each bus is walked.
  This code obviously doesn't support that.
  Maybe, sn_init_pci_controller() or something like that would be clearer.

o This bit of code belongs in the pcibios_fixup_bus() call path:
	+       /*
	+        * Generic Linux PCI Layer has created the pci_bus and pci_dev
	+        * structures - time for us to add our SN PLatform specific
	+        * information.
	+        */
	+
	+       while ((pci_dev 	+               pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pci_dev)) != NULL) {
	+               sn_pci_fixup_slot(pci_dev);
	+       }

  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.

o sn_pci_fixup_bus() should be called for each PCI root bus controller
  the firmware advertises. The loop in sn_pci_init() is hard coded
  to loop from 0 to 256 busses.
  Is ACPI the only way PCI host controllers are advertised?
  SN2 doesn't use a different method today?

  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.

o the BUG() in:

  	+       controller = sn_alloc_pci_sysdata();
	+       if (!controller) {
	+               BUG();
	+       }
  is redundant with the BUG in sn_alloc_pci_sysdata().

sorry for the initial bad advice and I hope this helps,
grant

  reply	other threads:[~2004-10-06 18:58 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 [this message]
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
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=20041006185739.GA25773@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: 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.