From: John Rose <johnrose@austin.ibm.com>
To: Linas Vepstas <linas@austin.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
long <tlnguyen@snoqualmie.dp.intel.com>,
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>,
Greg KH <greg@kroah.com>,
ak@muc.de, Paul Mackerras <paulus@samba.org>,
linuxppc64-dev <linuxppc64-dev@ozlabs.org>,
linux-pci@atrey.karlin.mff.cuni.cz,
Me Notes <johnrose@us.ibm.com>
Subject: Re: [PATCH 10/13]: PCI Err: PPC64-specific recovery infrastructure
Date: Wed, 29 Jun 2005 10:28:38 -0500 [thread overview]
Message-ID: <1120058918.19616.4.camel@sinatra.austin.ibm.com> (raw)
In-Reply-To: <20050628235956.GA6455@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
prev parent reply other threads:[~2005-06-29 15:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-28 23:59 [PATCH 10/13]: PCI Err: PPC64-specific recovery infrastructure Linas Vepstas
2005-06-29 4:34 ` Benjamin Herrenschmidt
2005-06-29 15:28 ` John Rose [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1120058918.19616.4.camel@sinatra.austin.ibm.com \
--to=johnrose@austin.ibm.com \
--cc=ak@muc.de \
--cc=benh@kernel.crashing.org \
--cc=greg@kroah.com \
--cc=johnrose@us.ibm.com \
--cc=linas@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=linuxppc64-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=tlnguyen@snoqualmie.dp.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox