public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: linas <linas@austin.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc64-dev@ozlabs.org, linux-kernel@vger.kernel.org,
	linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [PATCH 15/22] ppc64: PCI Error Recovery: PPC64 core recovery routines
Date: Thu, 13 Oct 2005 11:03:39 -0500	[thread overview]
Message-ID: <20051013160339.GT29826@austin.ibm.com> (raw)
In-Reply-To: <17228.56384.469138.175618@cargo.ozlabs.ibm.com>

On Wed, Oct 12, 2005 at 07:49:52PM +1000, Paul Mackerras was heard to remark:
> Linas writes:
> 
> > +	/* We might not have a pci device, if it was a config space read
> > +	 * that failed.  Find the pci device now.  */
> > +	if (!dev) {
> > +		while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
> > +			if (pci_device_to_OF_node(dev) == event->dn)
> > +				break;
> > +		}
> > +	}
> 
> Couldn't we just use PCI_DN(event->dn)->pcidev here?  Is there some
> reason why this would not work in some circumstances?  It would be
> nice to avoid this linear search.

Funny tha you mention this, I just chopped this out yesterday; its cruft
left over from back-when.

The reason I chopped this out is due to a bug regarding the handling 
of multi-function devices with the "new style" firmware interfaces.

With the new interfaces (i.e. those using ibm,get-config-addr-info),
every function on a pci card is labelled as a "partitionable endpoint".
By contrast, the current code assumes a "PE" is associated with a pci
card. As a result of this mismatch, the handling of multi-function
cards on systems with the new-style firmware is flubbed. (In particular,
the setup and use of config-space is muffed, resulting in crashes due
to access of i/o space that wasn't correctly set up). 

I'm trying several different approaches to fixing this.

1) consolidating multiple pci functions (multiple PE's) into a single 
   "pci card" and treating the thing as a unit.

2) Treating each PE as completely distinct, and handling each distinctly.

Each approach seems to have problems. Cross my fingers, hope to have 
something working later today; however, I'm irritated that I even need 
to solve his problem.

--linas

  reply	other threads:[~2005-10-13 16:04 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-06 23:20 [PATCH 0/22] ppc64: Full sequence of PCI Error recovery patches linas
2005-10-06 23:23 ` [PATCH 1/22] ppc64: Dynamic LPAR bugfix linas
2005-10-06 23:25 ` [PATCH 2/22] ppc64: Enable detection bugfix linas
2005-10-06 23:26 ` [PATCH 3/22] ppc64: EEH Recovery dispatcher thread linas
2005-10-06 23:28 ` [PATCH 4/22] ppc64: EEH Recovery support routines linas
2005-10-06 23:29 ` [PATCH 5/22] ppc64: Device BAR save and restore linas
2005-10-06 23:31 ` [PATCH 6/22] ppc64: PCI Error Recovery: documentation patch linas
2005-10-06 23:32 ` [PATCH 7/22] PCI Error Recovery: header file patch linas
2005-10-06 23:33 ` [PATCH 8/22] ppc64: Slot Marking Bugfix linas
2005-10-06 23:35 ` [PATCH 9/22] ppc64: DLPAR slot add and remove bugfixes linas
2005-10-06 23:36 ` [PATCH 10/22] ppc64: Crash on DLPAR PHB add linas
2005-10-06 23:39 ` [PATCH 11/22] ppc64: RPA PHP and EEH common code linas
2005-10-06 23:40 ` [PATCH 12/22] ppc64: RPA PHP cleanup linas
2005-10-06 23:44 ` [PATCH 13/22] ppc64: RPAPHP duplicated code removal linas
2005-10-06 23:46 ` [PATCH 14/22] ppc64: RPA PHP to EEH code movement linas
2006-01-07 21:28   ` Olaf Hering
2006-01-09 19:58     ` [PATCH]: ppowerpc: fix compile-time failure when EEH disabled linas
2005-10-06 23:47 ` [PATCH 15/22] ppc64: PCI Error Recovery: PPC64 core recovery routines linas
2005-10-12  9:49   ` Paul Mackerras
2005-10-13 16:03     ` linas [this message]
2005-10-06 23:53 ` [PATCH 16/22] PCI Address cache lookup code linas
2005-10-06 23:54 ` [PATCH 17/22] ppc64: New Partition Endpoin support linas
2005-10-06 23:55 ` [PATCH 18/22] PCI Error Recovery: IPR SCSI device driver linas
2005-10-06 23:56 ` [PATCH 19/22] PCI Error Recovery: Symbios " linas
2005-10-06 23:57 ` [PATCH 20/22] PCI Error Recovery: e100 network " linas
2005-10-11  0:10   ` Greg KH
2005-10-11 23:04     ` linas
2005-10-11 23:41       ` Paul Mackerras
2005-10-06 23:58 ` [PATCH 21/22] PCI Error Recovery: e1000 " linas
2005-10-06 23:59 ` [PATCH 22/22] PCI Error Recovery: ixgb " linas

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=20051013160339.GT29826@austin.ibm.com \
    --to=linas@austin.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=linuxppc64-dev@ozlabs.org \
    --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