[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <11777001852549-git-send-email-gregkh@suse.de>
Date: Fri, 27 Apr 2007 11:53:53 -0700
From: Greg Kroah-Hartman <gregkh@...e.de>
To: linux-kernel@...r.kernel.org
Cc: Cornelia Huck <cornelia.huck@...ibm.com>,
Kay Sievers <kay.sievers@...y.org>,
Eric Rannaud <eric.rannaud@...il.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...e.de>
Subject: [PATCH 39/46] s390: cio: Delay uevents for subchannels
From: Cornelia Huck <cornelia.huck@...ibm.com>
We often have the situation that we register a subchannel and start device
recognition, only to find out that the device is not usable after all, which
triggers an unregister of the subchannel. This often happens on hundreds of
subchannels on a LPAR, leading to a storm of events which aren't of any use.
Therefore, use uevent_suppress to delay the KOBJ_ADD uevent for a subchannel
until we know that its ccw_device is to be registered.
Signed-off-by: Cornelia Huck <cornelia.huck@...ibm.com>
Cc: Kay Sievers <kay.sievers@...y.org>
Cc: Eric Rannaud <eric.rannaud@...il.com>
Cc: Heiko Carstens <heiko.carstens@...ibm.com>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
---
drivers/s390/cio/device.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/s390/cio/device.c b/drivers/s390/cio/device.c
index 0335590..a23ff58 100644
--- a/drivers/s390/cio/device.c
+++ b/drivers/s390/cio/device.c
@@ -871,6 +871,12 @@ io_subchannel_register(struct work_struct *work)
}
goto out;
}
+ /*
+ * Now we know this subchannel will stay, we can throw
+ * our delayed uevent.
+ */
+ sch->dev.uevent_suppress = 0;
+ kobject_uevent(&sch->dev.kobj, KOBJ_ADD);
/* make it known to the system */
ret = ccw_device_register(cdev);
if (ret) {
--
1.5.1.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists