mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@samba.org>
To: Linas Vepstas <linas@austin.ibm.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org,
	Greg KH <greg@kroah.com>,
	linuxppc64-dev@ozlabs.org, linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [patch 8/8] PCI Error Recovery: PPC64 core recovery routines
Date: Mon, 29 Aug 2005 16:40:20 +1000	[thread overview]
Message-ID: <17170.44500.848623.139474@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <20050825161325.GG25174@austin.ibm.com>

Linas Vepstas writes:

> Actually, no.  There are three issues:
> 1) hotplug routines are called from within kernel. GregKH has stated on
>    multiple occasions that doing this is wrong/bad/evil. This includes
>    calling hot-unplug.
> 
> 2) As a result, the code to call hot-unplug is a bit messy. In
>    particular, there's a bit of hoop-jumping when hotplug is built as
>    as a module (and said hoops were wrecked recently when I moved the
>    code around, out of the rpaphp directory).

One way to clean this up would be to make rpaphp the driver for the
EADS bridges (from the pci code's point of view).  Then it would
automatically get included in the error recovery process and could do
whatever it should.

> 3) Hot-unplug causes scripts to run in user-space. There is no way to 
>    know when these scripts are done, so its not clear if we've waited
>    long enough before calling hot-add (or if waiting is even necessary).

OK, so let's just add a new hotplug event called KOBJ_ERROR or
something, which tells userspace that an error has occurred which has
made the device inaccessible.  Greg, would that be OK?

The only trouble with that is that if we don't have a hotplug bridge
driver loaded for the slot, we can't tell the driver that its device
has gone away.  I guess that's not a big problem in practice.

Paul.

  reply	other threads:[~2005-08-29  6:40 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050823231817.829359000@bilge>
2005-08-23 23:35 ` [patch 0/8] PCI Error Recovery patchset Linas Vepstas
     [not found] ` <20050823232140.337320000@bilge>
2005-08-23 23:39   ` [patch 2/8] PCI Error Recovery: header file patch Linas Vepstas
     [not found] ` <20050823232140.520090000@bilge>
2005-08-23 23:41   ` [patch 3/8] PCI Error Recovery: IPR SCSI device driver Linas Vepstas
     [not found] ` <20050823232140.903067000@bilge>
2005-08-23 23:43   ` [patch 4/8] PCI Error Recovery: Symbios " Linas Vepstas
     [not found] ` <20050823232141.286102000@bilge>
2005-08-23 23:45   ` [patch 5/8] PCI Error Recovery: e100 network " Linas Vepstas
     [not found] ` <20050823232141.925586000@bilge>
2005-08-23 23:46   ` [patch 6/8] PCI Error Recovery: e1000 " Linas Vepstas
     [not found] ` <20050823232142.651390000@bilge>
2005-08-23 23:47   ` [patch 7/8] PCI Error Recovery: ixgb " Linas Vepstas
     [not found] ` <20050823232143.003048000@bilge>
2005-08-23 23:47   ` [patch 8/8] PCI Error Recovery: PPC64 core recovery routines Linas Vepstas
2005-08-24  0:43     ` Paul Mackerras
2005-08-24  4:49       ` Paul Mackerras
2005-08-24 15:45     ` John Rose
2005-08-24 16:29       ` Linas Vepstas
2005-08-25  0:10         ` Paul Mackerras
2005-08-25  0:49           ` Benjamin Herrenschmidt
2005-08-25 16:21             ` Linas Vepstas
2005-08-25 21:43               ` Benjamin Herrenschmidt
2005-08-25 23:18                 ` Paul Mackerras
2005-08-25 23:37                   ` Benjamin Herrenschmidt
2005-08-29 16:00                     ` Linas Vepstas
2005-08-29 15:57                 ` Linas Vepstas
2005-08-25 16:13           ` Linas Vepstas
2005-08-29  6:40             ` Paul Mackerras [this message]
2005-08-29 16:09               ` Linas Vepstas
2005-08-30  4:44                 ` Paul Mackerras
2005-08-30 22:33                   ` John Rose
2005-08-29 20:26               ` John Rose
2005-08-29 20:31                 ` John Rose

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=17170.44500.848623.139474@cargo.ozlabs.ibm.com \
    --to=paulus@samba.org \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.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 \
    /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

all inboxes | Powered by JetHome®