On Wednesday, November 28, 2012 03:33:27 PM Toshi Kani wrote: > > > > > > > I think it has some challenge as well. We bind an ACPI driver > > > > > > > with > > > > > > > device_register(), which calls device_add()-> kobject_add(). So, > > > > > > > all > > > > > > > non-present ACPI device objects will show up in sysfs, unless we > > > > > > > can > > > > > > > change the core. This will change user interface. There can be > > > > > > > quite > > > > > > > many non-present devices in ACPI namespace depending on FW > > > > > > > implementation. > > > > > > > > > > > > If additional devices appear in sysfs, that's not a problem. If > > > > > > there > > > > > > were fewer of them, that would be a real one. :-) > > > > > > > > > > I see. I guess this means that once we expose all non-present devices > > > > > in sysfs, we cannot go back to the current way. So, we need to be > > > > > very > > > > > careful. Anyway, this model requires separate handling for static > > > > > ACPI > > > > > [1] and dynamic ACPI [2], which may make the state model complicated. > > > > > > > > > > 1. Static ACPI - No creation / deletion of acpi_device at hot-plug. > > > > > 2. Dynamic ACPI - Create acpi_device at hot-add, delete at hot-remove. > > > > > > > > Sure. The complication here is that we'll need to handle the removal of > > > > a bunch of struct acpi_device objects when a whole table goes away. > > > > > > > > However, first, we don't seem to handle table unloading now. At least > > > > acpi_unload_parent_table() is not called from anywhere as far as I can > > > > say. Second, we'll need to handle the removal of struct acpi_device > > > > objects > > > > _anyway_ on table unload, this way or another. > > > > > > AML is the one that requests loading/unloading of SSDT for dynamic ACPI. > > > In hot-add, _Lxx method executes AML_LOAD_OP or AML_LOAD_TABLE_OP to > > > load SSDT and then sends a notification to the OS. In hot-remove, _EJ0 > > > method executes AML_UNLOAD_OP to unload SSDT. Of course, ACPICA does > > > the actual work on behalf of AML. But this is not visible to ACPI core > > > or drivers, unless it checks ACPI namespace to see if any device objects > > > disappeared after _EJ0. > > > > Oh, we have a handler for that event, but we don't really use it. :-) > > > > And I wonder what happens to the struct acpi_device objects associated with > > the ACPI handles in the table being unloaded? > > If we use an ACPI handle that does not associate with a device object, > ACPICA returns AE_NOT_FOUND or AE_NOT_EXIST. But, we should remove > acpi_device that does not have its associated ACPI object. Currently, > we create acpi_device on hot-add and remove it on hot-remove, so it is > OK. But if we start creating acpi_device objects for non-present > devices, we need to worry about if acpi_device objects indeed have their > associated ACPI objects. That's the complication I mentioned above.
My question was about something different. Is it actually guaranteed that all struct device objects associated with the given ACPI table will be removed before that table is unloaded? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
