Re: [PATCH][2.6][CFT] rmmod floppy kills box fixes + default_device_remove

[John Levon]

On Tue, Sep 09, 2003 at 03:18:20PM -0400, Zwane Mwaikambo wrote:

> > Any thoughts on how to solve this?
> 
> How about something like the following, the kobj_type.done is passed from 
> the driver so the driver's presence can maintain it's persistence and 

This works. Repeat ad infinitum for all the other platform devices in
pcmcia etc, 99% of which don't need to release anything extra.

Alternatively why don't we do something like the below ? This still
allows platform devices to clean up if necessary, but solves the "wait
for last reference" on a sensible level IMHO.

Index: platform.c
===================================================================
RCS file: /home/cvs/linux-2.5/drivers/base/platform.c,v
retrieving revision 1.11
diff -u -p -r1.11 platform.c
--- platform.c	16 Aug 2003 05:00:10 -0000	1.11
+++ platform.c	9 Sep 2003 18:02:22 -0000
@@ -18,6 +18,16 @@ struct device legacy_bus = {
 	.bus_id		= "legacy",
 };
 
+
+static void platform_device_release(struct device * dev)
+{
+	struct platform_device * pdev = to_platform_device(dev);
+	if (pdev->release)
+		pdev->release(pdev);
+	complete(&pdev->done);
+}
+
+
 /**
  *	platform_device_register - add a platform-level device
  *	@dev:	platform device we're adding
@@ -32,6 +42,12 @@ int platform_device_register(struct plat
 		pdev->dev.parent = &legacy_bus;
 
 	pdev->dev.bus = &platform_bus_type;
+
+	if (pdev->dev.release) {
+		printk("use the other release dude\n");
+	}
+	pdev->dev.release = platform_device_release;
+	init_completion(&pdev->done);
 	
 	snprintf(pdev->dev.bus_id,BUS_ID_SIZE,"%s%u",pdev->name,pdev->id);
 
@@ -44,6 +60,7 @@ void platform_device_unregister(struct p
 {
 	if (pdev)
 		device_unregister(&pdev->dev);
+	wait_for_completion(&pdev->done);
 }
 
 
-- 
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/