PCI hotplug + EEH issues

[Todd Inglett]

On Wed, 2002-09-11 at 09:49, Benjamin Herrenschmidt wrote:
[...]
> >But now I am confused.  Do you really think we can share prom.c?  Or by
> >"various OF implementations tend to differ" are you talking only stuff
> >that zImage (or yaboot) has to do.  Is allocating memory the only
> >problem?
>
> I was talking about eventually keeping zImage/yaboot code split
> (and what's in prom_init.c).
> Allocating memory is one thing, dealing with displays another, well,
> we may be able to keep the same code, I'm just not sure it's worth it
> if moved to a zImage wrapper.
>
> prom.c, that deals with the device-tree during kernel lifetime, and
> other PCI<->OF, OF resource, etc... functions could probably be shared.

Pete just reminded me how prom.c and prom_init.c are split :).  All
along I was thinking we'd have a prom.c and a device_tree.c.  Just got
confused....

[...]
> >So should I make a stab at defining the of_* functions, or has someone
> >already done this?  One thing in particular I've never liked are the
> >find_* funcs that link stuff in ->next lists (or ->allnext lists in case
> >you need that 2nd query....).
>
> Well, they definitely cause interesting locking issues... How would
> you fix that ? Defining an opaque iterator type ? Just passing a
> device_node to start the search from ?

Yeah, I was thinking having a start node would make for the simplest
interface (where NULL means begin at the top, of course).  It's pretty
trival to traverse the tree -- even when you want to traverse all nodes
-- so I don't see any reason to keep the next and allnext ptrs.

I'm also not sure we need to cache the addresses and interrupts for pci
nodes.  Since access to these is not performance critical (i.e. only
during device init) can't we just have functions that given a specific
node could compute these values?  I've never understood why they needed
to be computed all up front.

> That reminds me we need to add a rwlock around device-tree functions
> since we can (and will occasionally) write to it (add properties
> is what I have in mind, locking on access to an actual property data
> is beyond the scope).

Good thought.  We may even add entire sub-trees during hot plug
operations.

-todd


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/