PCI hotplug + EEH issues

[Todd Inglett]

On Tue, 2002-09-10 at 13:14, Benjamin Herrenschmidt wrote:
>
> Ok, here we are mixing 2 different things
>
>  - The actual interface to OF, which is currently done in the
> kernel during the early init stage and could be moved to a
> wrapper
>
>  - The kernel's internal representation of the device-tree along
> with related "parsing" functions. This is used during most of the
> kernel's life and require no interaction with OF itself.

Yep, agreed.  In both cases I think code could be shared (or at least
identical).  Of course the 2nd would be 64-bit in ppc64, while the first
is 32-bit under both ppc32 and ppc64 (and could be the same object
files, in fact).


> Well, at least some of this code will stay platform specific,
> at least the one doing the actual interaction with OF as various
> OF implementation tend to differ significantly, especially
> regarding the way memory is allocated & mapped.

That's interesting.  I would have guessed the other way around, but I
haven't played with OF much on a mac, either :(.

> What I'm thinking about is, at first, sharing the code related
> to dealing with the actual device_node data structure (which should
> be cleaned up from old pmac cruft) and routines that deal with it
> during kernel lifetime, typically things like get_property, find_device,
> etc...
>
> While we are at it, I'd also pick a naming convention making these
> less prone to colision, like using "of_" prefix all the time.

Agreed.  This stuff needs janitor work first because it directly affects
the kernel.

[...]
> In ppc32, paulus did the split already between prom_init and prom.c
> The point here is to at least split what is related to live interaction
> with OF itself, and later dealing with the kernel internal representation
> of the device-tree
>
> 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?

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

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

-todd


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