[PATCH] FYI/ Re: PCI Error Recovery API Proposal (updated)

[Linas Vepstas]

On Fri, May 13, 2005 at 11:25:56AM -0500, John Rose was heard to remark:
>
> I don't think handle_eeh_events() or eeh_reset_device()
> belong in the RPA PCI hotplug driver.  

Suggestions where these should go? They got moved from arch/ppc64/kernel
to drivers/pci/hotplug at the urging of Paulus and GregKH; in part because 
rpaphp can be built as a module, whereas the the ppc64 bits cannot.  
Would a distinct file in drivers/pci/hotplug work? Or someething else?

> Looking at the patch, all EEH needs from PCI Hotplug are enable and
> disable functions.  The rpaphp driver could register disable/enable
> functions with eeh.c, and we could avoid introducing this unrelated
> code to the PCI Hotplug driver.

That's how it used to work; no one liked that idea.  But it doesn't hurt
to revisit.  I think the biggest problem here is module dependencies.
Alternately, we might struggle to find a generic
pci-error-recovery-on-top-of-pci-hotplug solution, but this may be 
premature at this point.

> One other quick comment:
> 
> +static struct device_node *
> +get_phb_of_device (struct pci_dev *dev)
> +{
> +	struct device_node *dn;
> +	struct pci_bus *bus;
> +
> +	while (1) {
> +		bus = dev->bus;
> +		if (!bus)
> +			break;
> +		dn = pci_bus_to_OF_node(bus);
> +
> +		if (dn->phb)
> +			return dn;
> +	
> +		dev = bus->self;
> +		BUG_ON (dev==NULL);
> +		if (dev == NULL)
> +			return NULL;
> +	}
> 
> Could you just use pci_device_to_OF_node(), then dn->phb?  This way, 
> you could avoid the loop.

Yes, except that not all dn's have phb's.  The goal here is to walk up
the tree, until a phb is found.

--linas