[PATCH] rpaphp broken in ameslab

[Paul Mackerras]

Linda,

>  Any changes to rpaphp(or rpaphp related) now should be posted on PCI
> hotplug mailing list (CC to kernel mailing list and Greg KH).  After

The change to drivers/pci/hotplug/rpaphp_core.c was simply that
rpaphp_disable_slot got duplicated due to a mis-merge.  I'm happy to
fix that in ameslab, particularly as it makes ameslab match upstream.
The other change I agree should go through Greg.

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.  I thought we were going to do
that via userspace.  Did Greg change his mind?

Just on that issue, in principle I think that it is reasonable for a
device driver to know about the state of the hardware it is
controlling (without needing userspace to tell it), and I consider
that the isolation status of a slot is part of that state.  So I think
that the rpaphp code *should* be informed by the eeh code when a slot
gets isolated.

I think that we have it the wrong way around though.  I think that the
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.  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.

Paul.

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