[PATCH] rpaphp broken in ameslab

[linas at austin.ibm.com]

On Wed, Jun 30, 2004 at 02:03:32PM -0500, Linda Xie wrote:
> Paul Mackerras wrote:
> >
> >By the way, I notice that upstream rpaphp_core.c now has the call to
> >eeh_register_disable_func(), although the actual function isn't
> >present in arch/ppc64/kernel/eeh.c.

Paul,

You and Anton are responsible for keeping the arch/ppc64 directories
in sync between sles9, ameslab, and akpm.  You are, after all, the
one true official, designated maintainer ... if the code hasn't been
migrated to akpm ... uuh ... what am I missing?

>From where I sit, the sles9 code is really the latest, greatest, most
tested and debugged arch/ppc64 code that there is.  This is the tree
that the developers get thier code/patches into.  Ameslab is distinctly
downlevel (for example, sles9-2.6.5-7.79 has an eeh.c that has a number
of patches, some up to a month old, that haven't yet appeared in ameslab.).
If the akpm tree doesn't have eeh_register_disable_func() then its
badly out of date, since that function got added many moons ago.

I'm somewhat concerned; the sles9 tree is now closed/closing, so
its a really great time to bring the other trees up-to-date, so
that we can continue to have a place to drop patches.

> >I think that we have it the wrong way around though.  I think that the

Yes, eeh_register_disable_func() is an ugly hack; its because rpaphp
can be built as a module, and eeh cannot, yett eeh needs to call into
rpaphp.

> >rpaphp code should do something analogous to a request_irq() to ask to
> >be informed about slot isolation events, rather than having the EEH
> >code call the rpaphp code to disable a slot.

Other than the module/not-a-module issue, why? I don't see any
particular advantage to an async, event-driven thingy as compared to
a plain-old subroutine call.  Subroutine calls are easy to make,
yuo don't need to invent infrastructure. KISS.

> > In fact I think the
> >separation is bogus; the EEH code and the rpaphp code are both part of
> >the driver for the RPA PCI subsystem.

prolly.  But note that the generic hotplug API's need to be extended
to give device drivers a mechanism to ask RPA PHP / EEH if a disconnect
event occured.  Last I talked to Greg, he wasn't willing to accept
something like that yet, so its a bit up in the air.  Personally,
I'd be happy to wait till more eeh prototype gets written before
propounding on archtiectural changes, (and happier still to find
the time to actually do it).

--linas


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