PCI hotplug + EEH issues

[Benjamin Herrenschmidt]

>Pete Bergner and I have talked about this a lot, but haven't had time to
>go anywhere with it.  What we'd like is to not only share code, but to
>move *all* of the Open Firmware code out of the kernel proper (i.e. into
>a wrapper or probably zImage).  This isn't a new idea, of course, as it
>has been discussed for ppc32 in the past -- I'm just not sure if it has
>gone anywhere there either.

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.

>The zImage code would build the device tree as a data structure,
>instantiate RTAS (if RTAS exists), initialize display devices, unpack
>the kernel and pass control to the kernel with birecs for all these
>things.  The kernel would either use the device tree data structure in
>place as-is, or it would copy it and/or alter the structure as it sees
>fit.  Since this code could be identical for ppc32 (in fact, it would
>run in 32-bit even in our hardware) it would be nice to share code -- or
>at least keep the code in sync.

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.

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.

>Is this still a the idea over in ppc32-land, or has the thinking changed
>over the past year or so? :)

Both ideas are around, near to no time is available, at least on
my side :( (and my current lack of ppc64 hw doesn't help though
that might be solved sooner or later).

>If the code really is shared I'm not sure where it goes either.  For the
>short term I wouldn't have a problem with just keeping it in sync.  It
>would be annoying, but not difficult.

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

That leads to an old question about how to share stuffs between arch's ;)

Ben.


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