On Fri, 2012-04-27 at 16:05 -0600, Toshi Kani wrote: > On Thu, 2012-04-26 at 11:10 -0600, Toshi Kani wrote: > > On Thu, 2012-04-26 at 09:16 -0600, Bjorn Helgaas wrote: > > > On Tue, Apr 10, 2012 at 4:21 PM, Toshi Kani <toshi.kani@xxxxxx> wrote: : > > > > > > > > +#if defined(CONFIG_ACPI_HOTPLUG_CPU) || defined(CONFIG_ACPI_HOTPLUG_MEMORY) ||\ > > > > + defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE) > > > > + capbuf[OSC_SUPPORT_TYPE] |= OSC_SB_HOTPLUG_OST_SUPPORT; > > > > +#endif > > > > > > This seems a bit strange to me. For one thing, the _OSC discussion > > > doesn't seem to indicate that _OST support is specific to CPU or > > > memory hotplug. If we tell the platform that we support _OST, the > > > platform can assume that we'll evaluate _OST for *any* device, which > > > is not the case. I guess this is just another reason why we need > > > hotplug support in the ACPI core, not in the individual drivers. Then > > > we wouldn't have the ifdefs at all. Thinking further, I am going to make the following changes to address this comment. 1. Add CONFIG_ACPI_HOTPLUG_OST (disable by default) When this option is set, the kernel calls _OSC with the hotplug _OST flag at boot-time. This replaces the current use of device-specific config options, such as CONFIG_ACPI_HOTPLUG_CPU. Also, the kernel only calls _OST when this option is set. In other words, all features in this patch set is disabled when this option is not set (default). This should address Shuah's concerns about pre-enablement as well. 2. Add support of container hotplug _OST will be supported for three major ACPI hotplug operations; CPU, memory and container. (This assumes PCI will use native hotplug going forward.) It will also support asynchronous hot-removal, such as KOBJ_OFFLINE -> udev -> eject. I will send updated _OST patches when they are ready. Thanks, -Toshi -- 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
