[PATCH] PPC64: EEH Recovery
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
> > I worry about duplicate devices across register/unregister and
> > 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
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
> > > -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.
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