[PATCH] PPC64: EEH Recovery

[Paul Mackerras]

Linas Vepstas writes:

> > 2. I don't see why the device nodes for the PCI subtree being reset
> >    would go away, and thus I don't see the need for your eeh_cfg_tree
> >    struct.
> 
> Its not the reset, its the hot-plug remove.  The hot plug code assumes
> that you are going to physically remove the device from the slot, so
> it removes the device_node as part of the "unconfig".  

OK, I missed that.  It seems a bit bogus to me.  Could you point me at
where in the code this happens?

> > 3. Is there a good reason why we can't use the assigned-addresses
> >    property on the relevant device tree nodes to tell us what to set
> >    the BARs to?
> 
> Yes, the reason is that after a reset, that property doesn't hold any 
> decent data.   I discussed this with the firmware developers, and thier 
> response was that it is the kernel's responsibility to compute 
> (or save/restore) such values.  (Except for bridges, which they will do for us).

The not holding any decent data is a consequence of the device nodes
getting thrown away, isn't it?  I fail to see how resetting the device
can of itself affect our copy of the device tree.

> > In particular I think it should be a
> >    userland write to a sysfs file that kicks off the restart process
> >    rather than it just happening after 5 seconds.  Anyway, what
> >    process or thread is executing that 5 second sleep?  Is it keventd
> >    or something?
> 
> Its a workqueue.

Which get run in keventd's context.  In other words no other
workqueues will get run during the 5 second sleep, or at least not on
that cpu.

Paul.