From: Toshi Kani <toshi.kani@hp.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: rjw@sisk.pl, lenb@kernel.org, akpm@linux-foundation.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, bhelgaas@google.com,
isimatu.yasuaki@jp.fujitsu.com, jiang.liu@huawei.com,
wency@cn.fujitsu.com, guohanjun@huawei.com, yinghai@kernel.org,
srivatsa.bhat@linux.vnet.ibm.com
Subject: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
Date: Wed, 30 Jan 2013 19:57:45 -0700 [thread overview]
Message-ID: <1359601065.15120.156.camel@misato.fc.hp.com> (raw)
In-Reply-To: <20130130045830.GH30002@kroah.com>
On Tue, 2013-01-29 at 23:58 -0500, Greg KH wrote:
> On Thu, Jan 10, 2013 at 04:40:19PM -0700, Toshi Kani wrote:
> > +/*
> > + * Hot-plug device information
> > + */
>
> Again, stop it with the "generic" hotplug term here, and everywhere
> else. You are doing a very _specific_ type of hotplug devices, so spell
> it out. We've worked hard to hotplug _everything_ in Linux, you are
> going to confuse a lot of people with this type of terms.
Agreed. I will clarify in all places.
> > +union shp_dev_info {
> > + struct shp_cpu {
> > + u32 cpu_id;
> > + } cpu;
>
> What is this? Why not point to the system device for the cpu?
This info is used to on-line a new CPU and create its system/cpu device.
In other word, a system/cpu device is created as a result of CPU
hotplug.
> > + struct shp_memory {
> > + int node;
> > + u64 start_addr;
> > + u64 length;
> > + } mem;
>
> Same here, why not point to the system device?
Same as above.
> > + struct shp_hostbridge {
> > + } hb;
> > +
> > + struct shp_node {
> > + } node;
>
> What happened here with these? Empty structures? Huh?
They are place holders for now. PCI bridge hot-plug and node hot-plug
are still very much work in progress, so I have not integrated them into
this framework yet.
> > +};
> > +
> > +struct shp_device {
> > + struct list_head list;
> > + struct device *device;
>
> No, make it a "real" device, embed the device into it.
This device pointer is used to send KOBJ_ONLINE/OFFLINE event during CPU
online/offline operation in order to maintain the current behavior. CPU
online/offline operation only changes the state of CPU, so its
system/cpu device continues to be present before and after an operation.
(Whereas, CPU hot-add/delete operation creates or removes a system/cpu
device.) So, this "*device" needs to be a pointer to reference an
existing device that is to be on-lined/off-lined.
> But, again, I'm going to ask why you aren't using the existing cpu /
> memory / bridge / node devices that we have in the kernel. Please use
> them, or give me a _really_ good reason why they will not work.
We cannot use the existing system devices or ACPI devices here. During
hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
device information in a platform-neutral way. During hot-add, we first
creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
but platform-neutral modules cannot use them as they are ACPI-specific.
Also, its system device (i.e. device under /sys/devices/system) has not
been created until the hot-add operation completes.
> > + enum shp_class class;
> > + union shp_dev_info info;
> > +};
> > +
> > +/*
> > + * Hot-plug request
> > + */
> > +struct shp_request {
> > + /* common info */
> > + enum shp_operation operation; /* operation */
> > +
> > + /* hot-plug event info: only valid for hot-plug operations */
> > + void *handle; /* FW handle */
> > + u32 event; /* FW event */
>
> What is this?
The shp_request describes a hotplug or online/offline operation that is
requested. In case of hot-plug request, the "*handle" describes a
target device (which is an ACPI device object) and the "event" describes
a type of request, such as hot-add or hot-delete.
Thanks,
-Toshi
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Toshi Kani <toshi.kani@hp.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-s390@vger.kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, linux-mm@kvack.org, yinghai@kernel.org,
linux-kernel@vger.kernel.org, rjw@sisk.pl,
linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com,
srivatsa.bhat@linux.vnet.ibm.com, guohanjun@huawei.com,
bhelgaas@google.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, lenb@kernel.org
Subject: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
Date: Wed, 30 Jan 2013 19:57:45 -0700 [thread overview]
Message-ID: <1359601065.15120.156.camel@misato.fc.hp.com> (raw)
In-Reply-To: <20130130045830.GH30002@kroah.com>
On Tue, 2013-01-29 at 23:58 -0500, Greg KH wrote:
> On Thu, Jan 10, 2013 at 04:40:19PM -0700, Toshi Kani wrote:
> > +/*
> > + * Hot-plug device information
> > + */
>
> Again, stop it with the "generic" hotplug term here, and everywhere
> else. You are doing a very _specific_ type of hotplug devices, so spell
> it out. We've worked hard to hotplug _everything_ in Linux, you are
> going to confuse a lot of people with this type of terms.
Agreed. I will clarify in all places.
> > +union shp_dev_info {
> > + struct shp_cpu {
> > + u32 cpu_id;
> > + } cpu;
>
> What is this? Why not point to the system device for the cpu?
This info is used to on-line a new CPU and create its system/cpu device.
In other word, a system/cpu device is created as a result of CPU
hotplug.
> > + struct shp_memory {
> > + int node;
> > + u64 start_addr;
> > + u64 length;
> > + } mem;
>
> Same here, why not point to the system device?
Same as above.
> > + struct shp_hostbridge {
> > + } hb;
> > +
> > + struct shp_node {
> > + } node;
>
> What happened here with these? Empty structures? Huh?
They are place holders for now. PCI bridge hot-plug and node hot-plug
are still very much work in progress, so I have not integrated them into
this framework yet.
> > +};
> > +
> > +struct shp_device {
> > + struct list_head list;
> > + struct device *device;
>
> No, make it a "real" device, embed the device into it.
This device pointer is used to send KOBJ_ONLINE/OFFLINE event during CPU
online/offline operation in order to maintain the current behavior. CPU
online/offline operation only changes the state of CPU, so its
system/cpu device continues to be present before and after an operation.
(Whereas, CPU hot-add/delete operation creates or removes a system/cpu
device.) So, this "*device" needs to be a pointer to reference an
existing device that is to be on-lined/off-lined.
> But, again, I'm going to ask why you aren't using the existing cpu /
> memory / bridge / node devices that we have in the kernel. Please use
> them, or give me a _really_ good reason why they will not work.
We cannot use the existing system devices or ACPI devices here. During
hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
device information in a platform-neutral way. During hot-add, we first
creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
but platform-neutral modules cannot use them as they are ACPI-specific.
Also, its system device (i.e. device under /sys/devices/system) has not
been created until the hot-add operation completes.
> > + enum shp_class class;
> > + union shp_dev_info info;
> > +};
> > +
> > +/*
> > + * Hot-plug request
> > + */
> > +struct shp_request {
> > + /* common info */
> > + enum shp_operation operation; /* operation */
> > +
> > + /* hot-plug event info: only valid for hot-plug operations */
> > + void *handle; /* FW handle */
> > + u32 event; /* FW event */
>
> What is this?
The shp_request describes a hotplug or online/offline operation that is
requested. In case of hot-plug request, the "*handle" describes a
target device (which is an ACPI device object) and the "event" describes
a type of request, such as hot-add or hot-delete.
Thanks,
-Toshi
WARNING: multiple messages have this Message-ID (diff)
From: Toshi Kani <toshi.kani@hp.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: rjw@sisk.pl, lenb@kernel.org, akpm@linux-foundation.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, bhelgaas@google.com,
isimatu.yasuaki@jp.fujitsu.com, jiang.liu@huawei.com,
wency@cn.fujitsu.com, guohanjun@huawei.com, yinghai@kernel.org,
srivatsa.bhat@linux.vnet.ibm.com
Subject: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
Date: Wed, 30 Jan 2013 19:57:45 -0700 [thread overview]
Message-ID: <1359601065.15120.156.camel@misato.fc.hp.com> (raw)
In-Reply-To: <20130130045830.GH30002@kroah.com>
On Tue, 2013-01-29 at 23:58 -0500, Greg KH wrote:
> On Thu, Jan 10, 2013 at 04:40:19PM -0700, Toshi Kani wrote:
> > +/*
> > + * Hot-plug device information
> > + */
>
> Again, stop it with the "generic" hotplug term here, and everywhere
> else. You are doing a very _specific_ type of hotplug devices, so spell
> it out. We've worked hard to hotplug _everything_ in Linux, you are
> going to confuse a lot of people with this type of terms.
Agreed. I will clarify in all places.
> > +union shp_dev_info {
> > + struct shp_cpu {
> > + u32 cpu_id;
> > + } cpu;
>
> What is this? Why not point to the system device for the cpu?
This info is used to on-line a new CPU and create its system/cpu device.
In other word, a system/cpu device is created as a result of CPU
hotplug.
> > + struct shp_memory {
> > + int node;
> > + u64 start_addr;
> > + u64 length;
> > + } mem;
>
> Same here, why not point to the system device?
Same as above.
> > + struct shp_hostbridge {
> > + } hb;
> > +
> > + struct shp_node {
> > + } node;
>
> What happened here with these? Empty structures? Huh?
They are place holders for now. PCI bridge hot-plug and node hot-plug
are still very much work in progress, so I have not integrated them into
this framework yet.
> > +};
> > +
> > +struct shp_device {
> > + struct list_head list;
> > + struct device *device;
>
> No, make it a "real" device, embed the device into it.
This device pointer is used to send KOBJ_ONLINE/OFFLINE event during CPU
online/offline operation in order to maintain the current behavior. CPU
online/offline operation only changes the state of CPU, so its
system/cpu device continues to be present before and after an operation.
(Whereas, CPU hot-add/delete operation creates or removes a system/cpu
device.) So, this "*device" needs to be a pointer to reference an
existing device that is to be on-lined/off-lined.
> But, again, I'm going to ask why you aren't using the existing cpu /
> memory / bridge / node devices that we have in the kernel. Please use
> them, or give me a _really_ good reason why they will not work.
We cannot use the existing system devices or ACPI devices here. During
hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
device information in a platform-neutral way. During hot-add, we first
creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
but platform-neutral modules cannot use them as they are ACPI-specific.
Also, its system device (i.e. device under /sys/devices/system) has not
been created until the hot-add operation completes.
> > + enum shp_class class;
> > + union shp_dev_info info;
> > +};
> > +
> > +/*
> > + * Hot-plug request
> > + */
> > +struct shp_request {
> > + /* common info */
> > + enum shp_operation operation; /* operation */
> > +
> > + /* hot-plug event info: only valid for hot-plug operations */
> > + void *handle; /* FW handle */
> > + u32 event; /* FW event */
>
> What is this?
The shp_request describes a hotplug or online/offline operation that is
requested. In case of hot-plug request, the "*handle" describes a
target device (which is an ACPI device object) and the "event" describes
a type of request, such as hot-add or hot-delete.
Thanks,
-Toshi
next prev parent reply other threads:[~2013-01-31 2:57 UTC|newest]
Thread overview: 251+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-10 23:40 [RFC PATCH v2 00/12] System device hot-plug framework Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-11 21:23 ` Rafael J. Wysocki
2013-01-11 21:23 ` Rafael J. Wysocki
2013-01-11 21:23 ` Rafael J. Wysocki
2013-01-14 15:33 ` Toshi Kani
2013-01-14 15:33 ` Toshi Kani
2013-01-14 15:33 ` Toshi Kani
2013-01-14 18:48 ` Rafael J. Wysocki
2013-01-14 18:48 ` Rafael J. Wysocki
2013-01-14 18:48 ` Rafael J. Wysocki
2013-01-14 19:02 ` Toshi Kani
2013-01-14 19:02 ` Toshi Kani
2013-01-14 19:02 ` Toshi Kani
2013-01-30 4:48 ` Greg KH
2013-01-30 4:48 ` Greg KH
2013-01-30 4:48 ` Greg KH
2013-01-31 1:15 ` Toshi Kani
2013-01-31 1:15 ` Toshi Kani
2013-01-31 1:15 ` Toshi Kani
2013-01-31 5:24 ` Greg KH
2013-01-31 5:24 ` Greg KH
2013-01-31 5:24 ` Greg KH
2013-01-31 14:42 ` Toshi Kani
2013-01-31 14:42 ` Toshi Kani
2013-01-31 14:42 ` Toshi Kani
2013-01-30 4:53 ` Greg KH
2013-01-30 4:53 ` Greg KH
2013-01-30 4:53 ` Greg KH
2013-01-31 1:46 ` Toshi Kani
2013-01-31 1:46 ` Toshi Kani
2013-01-31 1:46 ` Toshi Kani
2013-01-30 4:58 ` Greg KH
2013-01-30 4:58 ` Greg KH
2013-01-30 4:58 ` Greg KH
2013-01-31 2:57 ` Toshi Kani [this message]
2013-01-31 2:57 ` Toshi Kani
2013-01-31 2:57 ` Toshi Kani
2013-01-31 20:54 ` Rafael J. Wysocki
2013-01-31 20:54 ` Rafael J. Wysocki
2013-01-31 20:54 ` Rafael J. Wysocki
2013-02-01 1:32 ` Toshi Kani
2013-02-01 1:32 ` Toshi Kani
2013-02-01 1:32 ` Toshi Kani
2013-02-01 7:30 ` Greg KH
2013-02-01 7:30 ` Greg KH
2013-02-01 7:30 ` Greg KH
2013-02-01 20:40 ` Toshi Kani
2013-02-01 20:40 ` Toshi Kani
2013-02-01 20:40 ` Toshi Kani
2013-02-01 22:21 ` Rafael J. Wysocki
2013-02-01 22:21 ` Rafael J. Wysocki
2013-02-01 22:21 ` Rafael J. Wysocki
2013-02-01 23:12 ` Toshi Kani
2013-02-01 23:12 ` Toshi Kani
2013-02-01 23:12 ` Toshi Kani
2013-02-02 15:01 ` Greg KH
2013-02-02 15:01 ` Greg KH
2013-02-02 15:01 ` Greg KH
2013-02-04 0:28 ` Toshi Kani
2013-02-04 0:28 ` Toshi Kani
2013-02-04 0:28 ` Toshi Kani
2013-02-04 12:46 ` Greg KH
2013-02-04 12:46 ` Greg KH
2013-02-04 12:46 ` Greg KH
2013-02-04 16:46 ` Toshi Kani
2013-02-04 16:46 ` Toshi Kani
2013-02-04 16:46 ` Toshi Kani
2013-02-04 19:45 ` Rafael J. Wysocki
2013-02-04 19:45 ` Rafael J. Wysocki
2013-02-04 19:45 ` Rafael J. Wysocki
2013-02-04 20:59 ` Toshi Kani
2013-02-04 20:59 ` Toshi Kani
2013-02-04 20:59 ` Toshi Kani
2013-02-04 23:23 ` Rafael J. Wysocki
2013-02-04 23:23 ` Rafael J. Wysocki
2013-02-04 23:23 ` Rafael J. Wysocki
2013-02-04 23:33 ` Toshi Kani
2013-02-04 23:33 ` Toshi Kani
2013-02-04 23:33 ` Toshi Kani
2013-02-01 7:23 ` Greg KH
2013-02-01 7:23 ` Greg KH
2013-02-01 7:23 ` Greg KH
2013-02-01 22:12 ` Rafael J. Wysocki
2013-02-01 22:12 ` Rafael J. Wysocki
2013-02-01 22:12 ` Rafael J. Wysocki
2013-02-02 14:58 ` Greg KH
2013-02-02 14:58 ` Greg KH
2013-02-02 14:58 ` Greg KH
2013-02-02 20:15 ` Rafael J. Wysocki
2013-02-02 20:15 ` Rafael J. Wysocki
2013-02-02 20:15 ` Rafael J. Wysocki
2013-02-02 22:18 ` [PATCH?] Move ACPI device nodes under /sys/firmware/acpi (was: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework) Rafael J. Wysocki
2013-02-02 22:18 ` Rafael J. Wysocki
2013-02-02 22:18 ` Rafael J. Wysocki
2013-02-04 1:24 ` Greg KH
2013-02-04 1:24 ` Greg KH
2013-02-04 1:24 ` Greg KH
2013-02-04 12:34 ` Rafael J. Wysocki
2013-02-04 12:34 ` Rafael J. Wysocki
2013-02-04 12:34 ` Rafael J. Wysocki
2013-02-03 20:44 ` [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework Rafael J. Wysocki
2013-02-03 20:44 ` Rafael J. Wysocki
2013-02-03 20:44 ` Rafael J. Wysocki
2013-02-04 12:48 ` Greg KH
2013-02-04 12:48 ` Greg KH
2013-02-04 12:48 ` Greg KH
2013-02-04 14:21 ` Rafael J. Wysocki
2013-02-04 14:21 ` Rafael J. Wysocki
2013-02-04 14:21 ` Rafael J. Wysocki
2013-02-04 14:33 ` Greg KH
2013-02-04 14:33 ` Greg KH
2013-02-04 14:33 ` Greg KH
2013-02-04 20:07 ` Rafael J. Wysocki
2013-02-04 20:07 ` Rafael J. Wysocki
2013-02-04 20:07 ` Rafael J. Wysocki
2013-02-04 22:13 ` Toshi Kani
2013-02-04 22:13 ` Toshi Kani
2013-02-04 22:13 ` Toshi Kani
2013-02-04 23:52 ` Rafael J. Wysocki
2013-02-04 23:52 ` Rafael J. Wysocki
2013-02-04 23:52 ` Rafael J. Wysocki
2013-02-05 0:04 ` Greg KH
2013-02-05 0:04 ` Greg KH
2013-02-05 0:04 ` Greg KH
2013-02-05 1:02 ` Rafael J. Wysocki
2013-02-05 1:02 ` Rafael J. Wysocki
2013-02-05 1:02 ` Rafael J. Wysocki
2013-02-05 11:11 ` Rafael J. Wysocki
2013-02-05 11:11 ` Rafael J. Wysocki
2013-02-05 11:11 ` Rafael J. Wysocki
2013-02-05 18:39 ` Greg KH
2013-02-05 18:39 ` Greg KH
2013-02-05 18:39 ` Greg KH
2013-02-05 21:13 ` Rafael J. Wysocki
2013-02-05 21:13 ` Rafael J. Wysocki
2013-02-05 21:13 ` Rafael J. Wysocki
2013-02-05 0:55 ` Toshi Kani
2013-02-05 0:55 ` Toshi Kani
2013-02-05 0:55 ` Toshi Kani
2013-02-04 16:19 ` Toshi Kani
2013-02-04 16:19 ` Toshi Kani
2013-02-04 16:19 ` Toshi Kani
2013-02-04 19:43 ` Rafael J. Wysocki
2013-02-04 19:43 ` Rafael J. Wysocki
2013-02-04 19:43 ` Rafael J. Wysocki
2013-02-04 1:23 ` Greg KH
2013-02-04 1:23 ` Greg KH
2013-02-04 1:23 ` Greg KH
2013-02-04 13:41 ` Rafael J. Wysocki
2013-02-04 13:41 ` Rafael J. Wysocki
2013-02-04 13:41 ` Rafael J. Wysocki
2013-02-04 16:02 ` Toshi Kani
2013-02-04 16:02 ` Toshi Kani
2013-02-04 16:02 ` Toshi Kani
2013-02-04 19:48 ` Rafael J. Wysocki
2013-02-04 19:48 ` Rafael J. Wysocki
2013-02-04 19:48 ` Rafael J. Wysocki
2013-02-04 19:46 ` Toshi Kani
2013-02-04 19:46 ` Toshi Kani
2013-02-04 19:46 ` Toshi Kani
2013-02-04 20:12 ` Rafael J. Wysocki
2013-02-04 20:12 ` Rafael J. Wysocki
2013-02-04 20:12 ` Rafael J. Wysocki
2013-02-04 20:34 ` Toshi Kani
2013-02-04 20:34 ` Toshi Kani
2013-02-04 20:34 ` Toshi Kani
2013-02-04 23:19 ` Rafael J. Wysocki
2013-02-04 23:19 ` Rafael J. Wysocki
2013-02-04 23:19 ` Rafael J. Wysocki
2013-01-10 23:40 ` [RFC PATCH v2 02/12] ACPI: " Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-11 21:25 ` Rafael J. Wysocki
2013-01-11 21:25 ` Rafael J. Wysocki
2013-01-11 21:25 ` Rafael J. Wysocki
2013-01-14 15:53 ` Toshi Kani
2013-01-14 15:53 ` Toshi Kani
2013-01-14 15:53 ` Toshi Kani
2013-01-14 18:47 ` Rafael J. Wysocki
2013-01-14 18:47 ` Rafael J. Wysocki
2013-01-14 18:47 ` Rafael J. Wysocki
2013-01-14 18:42 ` Toshi Kani
2013-01-14 18:42 ` Toshi Kani
2013-01-14 18:42 ` Toshi Kani
2013-01-14 19:07 ` Rafael J. Wysocki
2013-01-14 19:07 ` Rafael J. Wysocki
2013-01-14 19:07 ` Rafael J. Wysocki
2013-01-14 19:21 ` Toshi Kani
2013-01-14 19:21 ` Toshi Kani
2013-01-14 19:21 ` Toshi Kani
2013-01-30 4:51 ` Greg KH
2013-01-30 4:51 ` Greg KH
2013-01-30 4:51 ` Greg KH
2013-01-31 1:38 ` Toshi Kani
2013-01-31 1:38 ` Toshi Kani
2013-01-31 1:38 ` Toshi Kani
2013-01-14 19:21 ` Greg KH
2013-01-14 19:21 ` Greg KH
2013-01-14 19:21 ` Greg KH
2013-01-14 19:29 ` Toshi Kani
2013-01-14 19:29 ` Toshi Kani
2013-01-14 19:29 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 03/12] drivers/base: Add " Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-30 4:54 ` Greg KH
2013-01-30 4:54 ` Greg KH
2013-01-30 4:54 ` Greg KH
2013-01-31 1:48 ` Toshi Kani
2013-01-31 1:48 ` Toshi Kani
2013-01-31 1:48 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 04/12] cpu: Add cpu hotplug handlers Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 05/12] mm: Add memory " Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 06/12] ACPI: Add ACPI bus " Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 07/12] ACPI: Add ACPI resource hotplug handler Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 08/12] ACPI: Update processor driver for hotplug framework Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 09/12] ACPI: Update memory " Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 10/12] ACPI: Update container " Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 11/12] cpu: Update sysfs cpu/online " Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 12/12] ACPI: Update sysfs eject " Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-10 23:40 ` Toshi Kani
2013-01-17 0:50 ` [RFC PATCH v2 00/12] System device hot-plug framework Rafael J. Wysocki
2013-01-17 0:50 ` Rafael J. Wysocki
2013-01-17 0:50 ` Rafael J. Wysocki
2013-01-17 0:50 ` Rafael J. Wysocki
2013-01-17 17:59 ` Toshi Kani
2013-01-17 17:59 ` Toshi Kani
2013-01-17 17:59 ` Toshi Kani
2013-01-17 17:59 ` Toshi Kani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1359601065.15120.156.camel@misato.fc.hp.com \
--to=toshi.kani@hp.com \
--cc=akpm@linux-foundation.org \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=guohanjun@huawei.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=jiang.liu@huawei.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=rjw@sisk.pl \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=wency@cn.fujitsu.com \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.