On Friday, February 08, 2013 08:59:44 PM Rafael J. Wysocki wrote: > On Friday, February 08, 2013 09:57:18 AM Toshi Kani wrote: > > On Fri, 2013-02-08 at 01:24 +0100, Rafael J. Wysocki wrote: > > > On Monday, February 04, 2013 12:47:31 AM Rafael J. Wysocki wrote: > > > > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > > > > > > > The only useful thing that the ACPI container driver does is to > > > > install system notify handlers for all container and module device > > > > objects it finds in the namespace. The driver structure, > > > > acpi_container_driver, and the data structures created by its > > > > .add() callback are in fact not used by the driver, so remove > > > > them entirely. > > > > > > > > It also makes a little sense to build that driver as a module, > > > > so make it non-modular and add its initialization to the > > > > namespace scanning code. > > > > > > > > In addition to that, make the namespace walk callback used for > > > > installing the notify handlers more straightforward. > > > > > > As pointed out by Toshi Kani, the above changes would make acpi_eject_store() > > > fail for containers and it is the only way to eject them currently, so patch > > > [2/2] is an improved version of this (with Toshi's changes folded in). > > > > > > Patch [1/2] is just a cleanup removing a useless #ifndef from acpi_eject_store(). > > > > Thanks for the update! They look good. For the series: > > > > Reviewed-by: Toshi Kani <toshi.kani@xxxxxx> > > Tested-by: Toshi Kani <toshi.kani@xxxxxx> > > > > BTW, did you intentionally keep the struct acpi_container definition in > > <acpi/container.h>? I deleted that one in my patch. > > No, I overlooked that part. I'll apply that part of your patch as a separate > patch on top of this one. Actually, I prefer to remove container.h entirely. I'll post a patch for that shortly. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
