Re: [PATCH 10/13]: PCI Err: PPC64-specific recovery infrastructure

[John Rose <johnrose@austin.ibm.com>]

(resend, dropped cc's)

Hi Linas-

The new functions eeh_report_error, eeh_report_reset,
eeh_report_resume, eeh_report_failure, eeh_reset_device, and
handle_eeh_events do not belong in this driver, imho.  Most of them
have nothing to do with PCI hotplug (eeh_report_*).  The ones that do
are clients of the enable/disable functionality, and as such are not
part of the actual hotplug implementation.  In my mind, it makes sense
to logically separate things when poissible.  I'm currently making an
effort to reduce bloat in this driver, and this would add to it.

The functions eeh_report_*, along with the handling routines, could
just as easily exist in the kernel or in a 3rd module
(drivers/pci/hotplug/rpaphp_pcierr.ko?).  You've suggested the third
module idea before, and I think it makes more sense than lumping this
in w/ rpaphp.  You could export [enable,disable]_slot from rpaphp, and
have a module dependency, similar to rpadlpar_io.

Thanks-
John

On Tue, 2005-06-28 at 18:59, Linas Vepstas wrote:
> pci-err-10-ppc64.patch
> 
> Implements ppc64-specific parts of detecting PCI bus errors,
> (via calls to the firmware to ask the hardware pci bridges)
> and the related mechanisms for reseting the affects PCI
> slots (again, via firmware calls).
> 
> Signed-off-by: Linas Vepstas <linas@linas.org>
> 
> ______________________________________________________________________
> _______________________________________________
> Linuxppc64-dev mailing list
> Linuxppc64-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc64-dev

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/