[PATCH] PPC64: EEH Recovery

Milton Miller miltonm at bga.com
Tue Nov 23 15:34:47 EST 2004


On Tue Nov 23 06:50:44 EST 2004, Linas Vepstas wrote:
> On Sat, Nov 20, 2004 at 05:11:53PM -0600, Milton D. Miller II was 
> heard to remark:

> ? Don't understand the question. PCI devices are arranged in a tree.
> One of the cards I test with has a bridge and several devices under it.
> So one has to walk the whole tree, which might be arbitrarily deep, to
> get to all of the devices.

Just because the devices are in a tree doesn't mean you need to store 
that structure.  If you only walk the tree in one path then you can 
walk the tree as you save the state and just store a linked list (such 
as linux/list.h).  (The power management code uses this trick).

> > 2) I object to grabbing pci devices so they don't disappear and 
> reappear.
> >    I worry about duplicate devices across register/unregister and 
> sysfs
> >    kobject lifetimes getting confused and duplicate names.
>
> I'll double-check, I was under the impression that the unregister
> happened, and I was just avodiing the final free().  Maybe I'm sorely
> mista
You seem to have a strong desire to save a struct pci_dev and then 
later reinsert that same device back in the tree.  You indicated that 
the pci layer actually is unregistering and re-registering the device.  
  Since you are not using the pci side of the device to restore the 
registers, it seems like a lot of work that is not needed.  Just write 
the bars back then start a new pci device with a new lifetime like a 
hotplug slot driver would.

Re information to save: you have identified the bars.  This information 
should be in the device tree as the assigned-addresses property.   You 
probably should also save the pci latency timer and a few other 
registers.

> > > -EXPORT_SYMBOL_GPL(rpaphp_find_hotplug_slot);
> >
> > not analyzed ...
>
> ??
You are removing a symbol export.   I haven't looked for other users of 
this.  If it has no current users it could be a separate patch.


milton

PS: I'll be on vacation for a week, so I might not respond to further 
mail for a bit.




More information about the Linuxppc64-dev mailing list