[PATCH] PPC64: EEH Recovery

[Linas Vepstas]

On Mon, Nov 22, 2004 at 10:34:47PM -0600, Milton Miller was heard to remark:
> 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).

Sure, yes. Trees can always be flattened to lists. But for this
particular case, this seems to make things more complex, not simpler. 
The current code would be smaller, faster & easier to debug than
having to convert it to use a linked list.

> >> 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.  

No not at all.  As I said, all I really wanted to do was to save the
bars. I actually thought about saving the bars in the device_node, 
but I then anticipated that some wise-guy on this mailing list suggest
that I save the bars in the pci_dev instead.   So I saved the bars
in pci_dev instead.   I did *not* anticipate your comments.  

I could save the bars in the device_node, I don't really care. 
Its the same amount of work either way.  I guess that there is
an intellectual challenge to understanding the finer points of 
kobjects which means that avoiding the use of kobjects and using
the device_node instead is indeed a safer thing to do.  So, OK,
you're right the BAR's should be saved in the device node.


> registers, it seems like a lot of work that is not needed.  Just write 

Its the same amount of cpu cycles, same amount of lines of code. 
As to work, its less work to not change anything :)  I'll convert the
code to use device node instead.

> Re information to save: you have identified the bars.  This information 
> should be in the device tree as the assigned-addresses property.   You 

I looked at that once, and decided I didn't like it; I vaguely remember
it wasn't exactly 1-1 with the bars, so I'd have to do more math to
restore from there.  I'd rather do a block copy.

> probably should also save the pci latency timer and a few other 
> registers.

Yeah I wondered about this, but maybe didn't wonder enough.  
I was vaguely thinking that the device driver would set these up,
but in fact, this is probably a bad assumption.  I'l crawl
through the PCI specs some more...

> >> > -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.

That subroutine no longer exists! (there are no other users;
I added this routine for EEH a long time ago, and was the only user.
Its been replaced by something better.)

--linas