Re: [PATCH 1/4] ACPI: Set hotplug _OST support bit to _OSC

[Toshi Kani]

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-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/