PCI hotplug + EEH issues

[Benjamin Herrenschmidt]

>> Making sure we agree on these and then sharing prom.c would be a good
>> first step. Then, bits of ppc32's pci.c dealing with pci<->OF relationship
>> would benefit from some cleaning & sharing as well, though I'm more and
>> ore thinkinh about going further and really sharing the whole pci.c
>
>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.

I have no definitive idea on how to implement the interation between
driverfs and the device-tree, but that also could be shared.

>> That leads to an old question about how to share stuffs between arch's ;)
>
>Well, in the short run I have no problem just sharing copies of the
>code.  Once they are identical, we could just put a comment at the top
>of each saying they a supposed to be in sync.  It might not last in the
>long run, but probably worth a shot.  Once we get enough code we can
>gripe on l-k about it as a non-theoretical problem.

Ok. Well, depending if apple ends up releasing 64 bits boxes or not,
more will have to be shared anyway ;)

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

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

Ben.


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