[PATCH] rpaphp broken in ameslab

[Greg KH]

On Wed, Jun 30, 2004 at 02:14:33PM -0500, linas at austin.ibm.com wrote:
> 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.

And that is the big problem.

Those patches/fixes should go to mainline, not directly to suse.  How
are they going to get back into mainline?  Are you all willing to now
send those same patches to the next distro that has a release (like Red
Hat?)  What about other distros that have full ppc64 releases (debian,
gentoo, etc.)

Change your development process to properly go to mainline and there
would not be any issues like this.

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

You should all be more concerned that all those suse patches are not
seen by anyone else.

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

Which is an ugly hack in and of itself.  I only oked it for now.

Actually, since everyone agrees that this isn't the way to go, I'll go
remove it :)

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

I wasn't willing to accept that, as that was the wrong way to do this.
It should be done from userspace with hotplug events like we mentioned.

And none of this "what happens about the root device" crud either, I've
seen your code in the kernel that checks for this today.  bah.

thanks,

greg k-h

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