From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: linux1394-devel@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org, damien_benoist@yahoo.com
Subject: [patch 2/3] ieee1394: don't drop nodes during bus reset series
Date: Sat, 16 Aug 2008 13:38:11 +0200 (CEST) [thread overview]
Message-ID: <tkrat.a3ef08493991acb0@s5r6.in-berlin.de> (raw)
In-Reply-To: <tkrat.bdb066b22ec930a0@s5r6.in-berlin.de>
nodemgr_node_probe checked for generation increments too late and
therefore prematurely reported nodes as "suspended".
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=11349 for me.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/ieee1394/nodemgr.c | 42 +++++++++++++++++++------------------
1 file changed, 22 insertions(+), 20 deletions(-)
Index: linux/drivers/ieee1394/nodemgr.c
===================================================================
--- linux.orig/drivers/ieee1394/nodemgr.c
+++ linux/drivers/ieee1394/nodemgr.c
@@ -1563,11 +1563,14 @@ struct probe_param {
bool probe_now;
};
-static int __nodemgr_node_probe(struct device *dev, void *data)
+static int node_probe(struct device *dev, void *data)
{
struct probe_param *param = (struct probe_param *)data;
struct node_entry *ne;
+ if (param->generation != get_hpsb_generation(param->hi->host))
+ return -EAGAIN;
+
ne = container_of(dev, struct node_entry, node_dev);
if (ne->needs_probe == param->probe_now)
nodemgr_probe_ne(param->hi, ne, param->generation);
@@ -1576,42 +1579,41 @@ static int __nodemgr_node_probe(struct d
static void nodemgr_node_probe(struct host_info *hi, int generation)
{
- struct hpsb_host *host = hi->host;
struct probe_param param;
param.hi = hi;
param.generation = generation;
- /* Do some processing of the nodes we've probed. This pulls them
+ /*
+ * Do some processing of the nodes we've probed. This pulls them
* into the sysfs layer if needed, and can result in processing of
* unit-directories, or just updating the node and it's
* unit-directories.
*
* Run updates before probes. Usually, updates are time-critical
- * while probes are time-consuming. (Well, those probes need some
- * improvement...) */
-
+ * while probes are time-consuming.
+ *
+ * Meanwhile, another bus reset may have happened. In this case we
+ * skip everything here and let the next bus scan handle it.
+ * Otherwise we may prematurely remove nodes which are still there.
+ */
param.probe_now = false;
- class_for_each_device(&nodemgr_ne_class, ¶m, __nodemgr_node_probe);
- param.probe_now = true;
- class_for_each_device(&nodemgr_ne_class, ¶m, __nodemgr_node_probe);
+ if (class_for_each_device(&nodemgr_ne_class, ¶m, node_probe) != 0)
+ return;
- /* If we had a bus reset while we were scanning the bus, it is
- * possible that we did not probe all nodes. In that case, we
- * skip the clean up for now, since we could remove nodes that
- * were still on the bus. Another bus scan is pending which will
- * do the clean up eventually.
- *
+ param.probe_now = true;
+ if (class_for_each_device(&nodemgr_ne_class, ¶m, node_probe) != 0)
+ return;
+ /*
* Now let's tell the bus to rescan our devices. This may seem
* like overhead, but the driver-model core will only scan a
* device for a driver when either the device is added, or when a
* new driver is added. A bus reset is a good reason to rescan
* devices that were there before. For example, an sbp2 device
* may become available for login, if the host that held it was
- * just removed. */
-
- if (generation == get_hpsb_generation(host))
- if (bus_rescan_devices(&ieee1394_bus_type))
- HPSB_DEBUG("bus_rescan_devices had an error");
+ * just removed.
+ */
+ if (bus_rescan_devices(&ieee1394_bus_type) != 0)
+ HPSB_DEBUG("bus_rescan_devices had an error");
}
static int nodemgr_send_resume_packet(struct hpsb_host *host)
--
Stefan Richter
-=====-==--- =--- =----
http://arcgraph.de/sr/
next prev parent reply other threads:[~2008-08-16 11:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <994096.81924.qm@web50505.mail.re2.yahoo.com>
[not found] ` <48A5A80A.90506@s5r6.in-berlin.de>
[not found] ` <48A6BA6F.2030000@s5r6.in-berlin.de>
2008-08-16 11:36 ` [patch 1/3] ieee1394: regression in 2.6.25: updates should happen before probes Stefan Richter
2008-08-16 11:38 ` Stefan Richter [this message]
2008-08-16 11:39 ` [patch 3/3] ieee1394: sbp2: let nodemgr retry node updates during bus reset series Stefan Richter
2008-08-19 19:28 ` [patch 2/3] ieee1394: don't drop nodes " Stefan Richter
2008-08-19 19:29 ` [patch 1/2] ieee1394: nodemgr clean up class iterators Stefan Richter
2008-08-19 19:30 ` [patch 2/2] ieee1394: survive a few seconds connection loss Stefan Richter
2008-10-10 17:13 ` [patch amendment] " Stefan Richter
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=tkrat.a3ef08493991acb0@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=damien_benoist@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
/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®