Thread (92 messages) 92 messages, 9 authors, 2012-12-15

Re: [RFC PATCH v3 3/3] acpi_memhotplug: Allow eject to proceed on rebind scenario

From: Vasilis Liaskovitis <hidden>
Date: 2012-12-06 09:30:28
Also in: linux-acpi, lkml

Hi,
On Thu, Nov 29, 2012 at 10:44:11AM -0700, Toshi Kani wrote:
On Thu, 2012-11-29 at 12:04 +0100, Vasilis Liaskovitis wrote:

Yes, that's what I had in mind along with device_lock().  I think the
lock is necessary to close the window.
http://www.spinics.net/lists/linux-mm/msg46973.html

But as I mentioned in other email, I prefer option 3 with
suppress_bind_attrs.  So, yes, please take a look to see how it works
out.
I tested the suppress_bind_attrs and it works by simply setting it to true
before driver registration e.g. 
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -783,7 +783,8 @@ int acpi_bus_register_driver(struct acpi_driver *driver)
 	driver->drv.name = driver->name;
 	driver->drv.bus = &acpi_bus_type;
 	driver->drv.owner = driver->owner;
-
+    if (!strcmp(driver->class, "memory"))
+        driver->drv.suppress_bind_attrs = true;
 	ret = driver_register(&driver->drv);
 	return ret;
 }
No bind/unbind sysfs files are created when using this, as expected.
I assume we only want to suppress for acpi_memhotplug
(class=ACPI_MEMORY_DEVICE_CLASS i.e. "memory") devices.

Is there agreement on what acpi_bus_trim behaviour and rollback (if any) we
want to have for the current ACPI framework (partial trim or full trim on
failure)?

thanks,

- Vasilis

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help