PATCH-ACPI based CPU hotplug[0/6]
Subsystems (7)
Hi Len,
I am resending the following set of patches which support ACPI based physical
CPU hotplug for IA64 platform, after having including all the community feedback(of course I got very thin feedback) which I got on acpi-devel mailing list.
This set of patches has been tested on linux-2.6.9-rc2. Also this time I am cc'ing ia64/lkml mailing lists as patch 3/6 and patch 4/6 touches arch specific files.
Details:(Applies cleanly onto linux-2.6.9-rc2) Patch[1/6]- Core ACPI enhancement support
Patch[2/6]- ACPI hotplug eject interface support Patch[3/6]- Arch specific support for mapping lsapic to cpu Patch[4/6]- Dynamic cpu registration and unregistration support Patch[5/6]- Extend ACPI processor driver to support Hotplug Patch[6/6]- ACPI container driver(New driver)
Please consider applying this patch onto your test tree.
Thanks,
Anil S Keshavamurthy
Re: PATCH-ACPI based CPU hotplug[0/6]-Core ACPI enhancement support
---
Name:acpi_core.patch
Status: Tested on 2.6.9-rc2
Depends: None
Version: applies on 2.6.9-rc2
Description:
This patch provides core hotplug support in acpi by providing acpi_bus_trim(), acpi_bus_remove() and acpi_pci_unbind() which does exactly reverse of acpi_bus_scan(), acpi_bus_add() and acpi_pci_bind().
---
linux-2.6.9-rc2-askeshav/drivers/acpi/acpi_ksyms.c | 3 linux-2.6.9-rc2-askeshav/drivers/acpi/bus.c | 4 linux-2.6.9-rc2-askeshav/drivers/acpi/pci_bind.c | 45 +++++++ linux-2.6.9-rc2-askeshav/drivers/acpi/pci_irq.c | 42 ++++++- linux-2.6.9-rc2-askeshav/drivers/acpi/scan.c | 107 +++++++++++++++++-- linux-2.6.9-rc2-askeshav/include/acpi/acpi_bus.h | 9 + linux-2.6.9-rc2-askeshav/include/acpi/acpi_drivers.h | 2 7 files changed, 194 insertions(+), 18 deletions(-)
include/acpi/acpi_bus.h renamed from include/acpi/acpi_bus.h~acpi_core +8 -1
@@ -104,6 +104,7 @@ typedef int (*acpi_op_suspend) (struct atypedef int (*acpi_op_resume ) (struct acpi_device *device,int state);typedef int (*acpi_op_scan ) (struct acpi_device *device);typedef int (*acpi_op_bind ) (struct acpi_device *device); +typedef int (*acpi_op_unbind ) (struct acpi_device *device);struct acpi_device_ops {acpi_op_add add;
@@ -115,6 +116,7 @@ struct acpi_device_ops {acpi_op_resume resume;acpi_op_scan scan;acpi_op_bind bind; +acpi_op_unbind unbind; };struct acpi_driver {
@@ -313,7 +315,8 @@ extern struct subsystem acpi_subsys;* External Functions */ -int acpi_bus_get_device (acpi_handle ,struct acpi_device **device); +int acpi_bus_get_device (acpi_handle handle,struct acpi_device **device); +void acpi_bus_data_handler (acpi_handle handle,u32 function,void *context);int acpi_bus_get_status (struct acpi_device *device);int acpi_bus_get_power (acpi_handle handle,int *state);int acpi_bus_set_power (acpi_handle handle,int state);
@@ -321,6 +324,10 @@ int acpi_bus_generate_event (struct acpiint acpi_bus_receive_event (struct acpi_bus_event *event);int acpi_bus_register_driver (struct acpi_driver *driver);int acpi_bus_unregister_driver (struct acpi_driver *driver); +int acpi_bus_scan (struct acpi_device *start); +void acpi_bus_trim (struct acpi_device *start,int rmdevice); +int acpi_bus_add (struct acpi_device **child,struct acpi_device *parent,acpi_handle handle,int type); +int acpi_create_dir (struct acpi_device *);void acpi_remove_dir (struct acpi_device *);
drivers/acpi/acpi_ksyms.c renamed from drivers/acpi/acpi_ksyms.c~acpi_core +3 -0
@@ -135,6 +135,9 @@ EXPORT_SYMBOL(acpi_bus_generate_event);EXPORT_SYMBOL (acpi_bus_receive_event);EXPORT_SYMBOL (acpi_bus_register_driver);EXPORT_SYMBOL (acpi_bus_unregister_driver); +EXPORT_SYMBOL (acpi_bus_scan); +EXPORT_SYMBOL (acpi_bus_trim); +EXPORT_SYMBOL (acpi_bus_add);#endif /*CONFIG_ACPI_BUS*/
drivers/acpi/scan.c renamed from drivers/acpi/scan.c~acpi_core +97 -10
163 lines not on this page · raw message
include/acpi/acpi_drivers.h renamed from include/acpi/acpi_drivers.h~acpi_core +2 -0
@@ -61,12 +61,14 @@ int acpi_pci_link_get_irq (acpi_handle h/* ACPI PCI Interrupt Routing (pci_irq.c) */ int acpi_pci_irq_add_prt (acpi_handle handle,int segment,int bus); +void acpi_pci_irq_del_prt (int segment,int bus);/* ACPI PCI Device Binding (pci_bind.c) */ struct pci_bus ;int acpi_pci_bind (struct acpi_device *device); +int acpi_pci_unbind (struct acpi_device *device);int acpi_pci_bind_root (struct acpi_device *device,struct acpi_pci_id *id,struct pci_bus *bus);/* Arch-defined function to add a bus to the system */
drivers/acpi/pci_irq.c renamed from drivers/acpi/pci_irq.c~acpi_core +39 -3
85 lines not on this page · raw message
drivers/acpi/pci_bind.c renamed from drivers/acpi/pci_bind.c~acpi_core +45 -0
63 lines not on this page · raw message
drivers/acpi/bus.c renamed from drivers/acpi/bus.c~acpi_core +0 -4
@@ -53,10 +53,6 @@ struct proc_dir_entry *acpi_root_dir;Device Management -------------------------------------------------------------------------- */ -extern void acpi_bus_data_handler ( -acpi_handle handle, -u32 function, -void *context); int acpi_bus_get_device ( acpi_handle handle,
_
PATCH-ACPI based CPU hotplug[1/6]-ACPI core enhancement support
In reply to Keshavamurthy Anil S---
Name:acpi_core.patch
Status: Tested on 2.6.9-rc2
Depends: None
Version: applies on 2.6.9-rc2
Description:
This patch provides core hotplug support in acpi by providing acpi_bus_trim(), acpi_bus_remove() and acpi_pci_unbind() which does exactly reverse of acpi_bus_scan(), acpi_bus_add() and acpi_pci_bind().
---
linux-2.6.9-rc2-askeshav/drivers/acpi/acpi_ksyms.c | 3 linux-2.6.9-rc2-askeshav/drivers/acpi/bus.c | 4 linux-2.6.9-rc2-askeshav/drivers/acpi/pci_bind.c | 45 +++++++ linux-2.6.9-rc2-askeshav/drivers/acpi/pci_irq.c | 42 ++++++- linux-2.6.9-rc2-askeshav/drivers/acpi/scan.c | 107 +++++++++++++++++-- linux-2.6.9-rc2-askeshav/include/acpi/acpi_bus.h | 9 + linux-2.6.9-rc2-askeshav/include/acpi/acpi_drivers.h | 2 7 files changed, 194 insertions(+), 18 deletions(-)
include/acpi/acpi_bus.h renamed from include/acpi/acpi_bus.h~acpi_core +8 -1
@@ -104,6 +104,7 @@ typedef int (*acpi_op_suspend) (struct atypedef int (*acpi_op_resume ) (struct acpi_device *device,int state);typedef int (*acpi_op_scan ) (struct acpi_device *device);typedef int (*acpi_op_bind ) (struct acpi_device *device); +typedef int (*acpi_op_unbind ) (struct acpi_device *device);struct acpi_device_ops {acpi_op_add add;
@@ -115,6 +116,7 @@ struct acpi_device_ops {acpi_op_resume resume;acpi_op_scan scan;acpi_op_bind bind; +acpi_op_unbind unbind; };struct acpi_driver {
@@ -313,7 +315,8 @@ extern struct subsystem acpi_subsys;* External Functions */ -int acpi_bus_get_device (acpi_handle ,struct acpi_device **device); +int acpi_bus_get_device (acpi_handle handle,struct acpi_device **device); +void acpi_bus_data_handler (acpi_handle handle,u32 function,void *context);int acpi_bus_get_status (struct acpi_device *device);int acpi_bus_get_power (acpi_handle handle,int *state);int acpi_bus_set_power (acpi_handle handle,int state);
@@ -321,6 +324,10 @@ int acpi_bus_generate_event (struct acpiint acpi_bus_receive_event (struct acpi_bus_event *event);int acpi_bus_register_driver (struct acpi_driver *driver);int acpi_bus_unregister_driver (struct acpi_driver *driver); +int acpi_bus_scan (struct acpi_device *start); +void acpi_bus_trim (struct acpi_device *start,int rmdevice); +int acpi_bus_add (struct acpi_device **child,struct acpi_device *parent,acpi_handle handle,int type); +int acpi_create_dir (struct acpi_device *);void acpi_remove_dir (struct acpi_device *);
drivers/acpi/acpi_ksyms.c renamed from drivers/acpi/acpi_ksyms.c~acpi_core +3 -0
@@ -135,6 +135,9 @@ EXPORT_SYMBOL(acpi_bus_generate_event);EXPORT_SYMBOL (acpi_bus_receive_event);EXPORT_SYMBOL (acpi_bus_register_driver);EXPORT_SYMBOL (acpi_bus_unregister_driver); +EXPORT_SYMBOL (acpi_bus_scan); +EXPORT_SYMBOL (acpi_bus_trim); +EXPORT_SYMBOL (acpi_bus_add);#endif /*CONFIG_ACPI_BUS*/
drivers/acpi/scan.c renamed from drivers/acpi/scan.c~acpi_core +97 -10
163 lines not on this page · raw message
include/acpi/acpi_drivers.h renamed from include/acpi/acpi_drivers.h~acpi_core +2 -0
@@ -61,12 +61,14 @@ int acpi_pci_link_get_irq (acpi_handle h/* ACPI PCI Interrupt Routing (pci_irq.c) */ int acpi_pci_irq_add_prt (acpi_handle handle,int segment,int bus); +void acpi_pci_irq_del_prt (int segment,int bus);/* ACPI PCI Device Binding (pci_bind.c) */ struct pci_bus ;int acpi_pci_bind (struct acpi_device *device); +int acpi_pci_unbind (struct acpi_device *device);int acpi_pci_bind_root (struct acpi_device *device,struct acpi_pci_id *id,struct pci_bus *bus);/* Arch-defined function to add a bus to the system */
drivers/acpi/pci_irq.c renamed from drivers/acpi/pci_irq.c~acpi_core +39 -3
85 lines not on this page · raw message
drivers/acpi/pci_bind.c renamed from drivers/acpi/pci_bind.c~acpi_core +45 -0
63 lines not on this page · raw message
drivers/acpi/bus.c renamed from drivers/acpi/bus.c~acpi_core +0 -4
@@ -53,10 +53,6 @@ struct proc_dir_entry *acpi_root_dir;Device Management -------------------------------------------------------------------------- */ -extern void acpi_bus_data_handler ( -acpi_handle handle, -u32 function, -void *context); int acpi_bus_get_device ( acpi_handle handle,
_
A message that is not in the archive (sent off-list or not yet received): 20040920093402.C14208-39QZ/XbsZ5/mO6KZMuUCQVaTQe2KTcn/@public.gmane.org
Re: PATCH-ACPI based CPU hotplug[1/6]-ACPI core enhancement support
T24gTW9uZGF5IDIwIFNlcHRlbWJlciAyMDA0IDExOjM0IGFtLCBLZXNoYXZhbXVydGh5IEFuaWwg UyB3cm90ZToKPiArdm9pZAo+ICthY3BpX2J1c190cmltKHN0cnVjdCBhY3BpX2RldmljZaCgoKCg oKAqc3RhcnQsCj4gK6CgoKCgoKCgoKCgoKCgoGludCBybWRldmljZSkKPiArewo+ICugoKCgoKCg YWNwaV9zdGF0dXOgoKCgoKCgoKCgoKCgc3RhdHVzID0gQUVfT0s7Cj4gK6CgoKCgoKBzdHJ1Y3Qg YWNwaV9kZXZpY2WgoKCgoKAqcGFyZW50ID0gTlVMTDsKPiAroKCgoKCgoHN0cnVjdCBhY3BpX2Rl dmljZaCgoKCgoCpjaGlsZCA9IE5VTEw7Cj4gK6CgoKCgoKBhY3BpX2hhbmRsZaCgoKCgoKCgoKCg oKBwaGFuZGxlID0gMDsKPiAroKCgoKCgoGFjcGlfaGFuZGxloKCgoKCgoKCgoKCgoGNoYW5kbGUg PSAwOwo+ICsKPiAroKCgoKCgoHBhcmVudCCgPSBzdGFydDsKPiAroKCgoKCgoHBoYW5kbGUgPSBz dGFydC0+aGFuZGxlOwoKCldoeSBkbyBhbGwgdGhlc2UgdmFyaWFibGVzIGhhdmUgdG8gYmUgaW5p dGlhbGl6ZWQ/IHBhcmVudCBhbmQgcGhhbmRsZSBhcmUKc2V0IHVwIGV4cGxpY2l0bHkgY291cGxl IG9mIGxpbmVzIGJlbG93LCB0aGUgcmVzdCBpcyBvbmx5IHVzZWQgc2FmZWx5CmFzIHdlbGwuLi4K CkFsc28sIGludHJvZHVjaW5nIHJlY3Vyc2lvbiAoZGVwdGggZG9lcyBub3Qgc2VlbSB0byBiZSBs aW1pdGVkIGhlcmUpIGlzCm5vdCBhIGdvb2QgaWRlYSBJTUhPIC0gYmV0dGVyIGNvbnZlcnQgaXQg aW50byBpdGVyYXRpb24gdG8gYXZvaWQgc3RhY2sKcHJvYmxlbXMgZG93biB0ZWggcm9hZC4KCi0t IApEbWl0cnkK
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
Re: [ACPI] PATCH-ACPI based CPU hotplug[1/6]-ACPI core enhancement support
Quoted 10 lines · Dmitry Torokhov
Quoted 9 lines · Keshavamurthy Anil S
drivers/acpi/scan.c renamed from drivers/acpi/scan.c~acpi_core +9
-0+void +acpi_bus_trim(struct acpi_device *start, + int rmdevice) +{ + acpi_status status = AE_OK; + struct acpi_device *parent = NULL; + struct acpi_device *child = NULL; + acpi_handle phandle = 0; + acpi_handle chandle = 0;
Quoted 8 lines
Quoted 3 lines
+
+ parent = start;
+ phandle =start->handle;Why do all these variables have to be initialized? parent and phandle are set up explicitly couple of lines below, the rest is only used safely as well...
You are correct, variable initialization can be removed. I will do this.
Quoted 4 lines
Also, introducing recursion (depth does not seem to be limited here) is not a good idea IMHO - better convert it into iteration to avoid stack problems down teh road.
Humm, I guess recursion should be fine and even though the code does not have an explicit limit, the ACPI namespace describing the Ejectable device will limit the number of recursible devices. And I believe this won;t be more than 3 to 4 level depth. Hence recursion is fine here.
If you still strongly believe that recursion is not the right choice here, let me know and I will convert it to iteration.
Thanks,
Anil
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ACPI] PATCH-ACPI based CPU hotplug[1/6]-ACPI core enhancement support
Quoted 11 lines · Keshavamurthy Anil S
Quoted 3 lines · Dmitry Torokhov
Also, introducing recursion (depth does not seem to be limited here) is not a good idea IMHO - better convert it into iteration to avoid stack problems down teh road.
Humm, I guess recursion should be fine and even though the code does not have an explicit limit, the ACPI namespace describing the Ejectable device will limit the number of recursible devices. And I believe this won;t be more than 3 to 4 level depth. Hence recursion is fine here.
If you still strongly believe that recursion is not the right choice here, let me know and I will convert it to iteration.
I'm also in favor of removing the recursion, if only because it allows local analysis. I.e., a correctness argument based solely on the code in the patch is much more useful than one that relies on properties of an external and mostly unknown ACPI namespace.
Re: [ACPI] PATCH-ACPI based CPU hotplug[1/6]-ACPI core enhancement support
Quoted 10 lines · Bjorn Helgaas
Quoted 9 lines · Keshavamurthy Anil S
Quoted 3 lines · Dmitry Torokhov
Also, introducing recursion (depth does not seem to be limited here) is not a good idea IMHO - better convert it into iteration to avoid stack problems down teh road.
Humm, I guess recursion should be fine and even though the code does not have an explicit limit, the ACPI namespace describing the Ejectable device will limit the number of recursible devices. And I believe this won;t be more than 3 to 4 level depth. Hence recursion is fine here.
Quoted 7 lines
Quoted 2 lines
If you still strongly believe that recursion is not the right choice here, let me know and I will convert it to iteration.
I'm also in favor of removing the recursion, if only because it allows local analysis. I.e., a correctness argument based solely on the code in the patch is much more useful than one that relies on properties of an external and mostly unknown ACPI namespace.
Okay, I am convinced, I will post an updated patch to address this soon. Again thanks for the feedback and more comments are welcome:)
-Anil
Re: [ACPI] PATCH-ACPI based CPU hotplug[1/6]-ACPI core enhancement support
Quoted 10 lines · Keshavamurthy Anil S
Quoted 6 lines · Bjorn Helgaas
Quoted 1 line · Keshavamurthy Anil S
On Mon, Sep 20, 2004 at 01:26:44PM -0500, Dmitry Torokhov wrote:
I'm also in favor of removing the recursion, if only because it allows local analysis. I.e., a correctness argument based solely on the code in the patch is much more useful than one that relies on properties of an external and mostly unknown ACPI namespace.
Okay, I am convinced, I will post an updated patch to address this soon. Again thanks for the feedback and more comments are welcome:)
Hi Bjorn,
I reworked my patch based on the review feedback I got. Please let me know
if you have any other issues.
Changes from previous version
- Changed acpi_bus_trim() from recursion version to non-recursive version
- Removed unnecessary local varable initializations.
Thanks,
Anil
---
Name:acpi_core.patch
Status: Tested on 2.6.9-rc2
Depends: None
Version: applies on 2.6.9-rc2
Description:
This patch provides core hotplug support in acpi by providing acpi_bus_trim(), acpi_bus_remove() and acpi_pci_unbind()
which does exactly reverse of acpi_bus_scan(), acpi_bus_add()
and acpi_pci_bind().
Changes from previous version
- Changed acpi_bus_trim() from recursion version to interation version
- Removed unnecessary local varable initializations.
---
linux-2.6.9-rc2-askeshav/drivers/acpi/acpi_ksyms.c | 3 linux-2.6.9-rc2-askeshav/drivers/acpi/bus.c | 4 linux-2.6.9-rc2-askeshav/drivers/acpi/pci_bind.c | 45 ++++++ linux-2.6.9-rc2-askeshav/drivers/acpi/pci_irq.c | 42 +++++- linux-2.6.9-rc2-askeshav/drivers/acpi/scan.c | 131 +++++++++++++++++-- linux-2.6.9-rc2-askeshav/include/acpi/acpi_bus.h | 10 + linux-2.6.9-rc2-askeshav/include/acpi/acpi_drivers.h | 2 7 files changed, 220 insertions(+), 17 deletions(-)
include/acpi/acpi_bus.h renamed from include/acpi/acpi_bus.h~acpi_core +9 -1
@@ -104,6 +104,7 @@ typedef int (*acpi_op_suspend) (struct atypedef int (*acpi_op_resume ) (struct acpi_device *device,int state);typedef int (*acpi_op_scan ) (struct acpi_device *device);typedef int (*acpi_op_bind ) (struct acpi_device *device); +typedef int (*acpi_op_unbind ) (struct acpi_device *device);struct acpi_device_ops {acpi_op_add add;
@@ -115,6 +116,7 @@ struct acpi_device_ops {acpi_op_resume resume;acpi_op_scan scan;acpi_op_bind bind; +acpi_op_unbind unbind; };struct acpi_driver {
@@ -313,7 +315,8 @@ extern struct subsystem acpi_subsys;* External Functions */ -int acpi_bus_get_device (acpi_handle ,struct acpi_device **device); +int acpi_bus_get_device (acpi_handle handle,struct acpi_device **device); +void acpi_bus_data_handler (acpi_handle handle,u32 function,void *context);int acpi_bus_get_status (struct acpi_device *device);int acpi_bus_get_power (acpi_handle handle,int *state);int acpi_bus_set_power (acpi_handle handle,int state);
@@ -321,6 +324,11 @@ int acpi_bus_generate_event (struct acpiint acpi_bus_receive_event (struct acpi_bus_event *event);int acpi_bus_register_driver (struct acpi_driver *driver);int acpi_bus_unregister_driver (struct acpi_driver *driver); +int acpi_bus_scan (struct acpi_device *start); +int acpi_bus_trim (struct acpi_device *start,int rmdevice); +int acpi_bus_add (struct acpi_device **child,struct acpi_device *parent, +acpi_handle handle,int type); +int acpi_create_dir (struct acpi_device *);void acpi_remove_dir (struct acpi_device *);
drivers/acpi/acpi_ksyms.c renamed from drivers/acpi/acpi_ksyms.c~acpi_core +3 -0
@@ -135,6 +135,9 @@ EXPORT_SYMBOL(acpi_bus_generate_event);EXPORT_SYMBOL (acpi_bus_receive_event);EXPORT_SYMBOL (acpi_bus_register_driver);EXPORT_SYMBOL (acpi_bus_unregister_driver); +EXPORT_SYMBOL (acpi_bus_scan); +EXPORT_SYMBOL (acpi_bus_trim); +EXPORT_SYMBOL (acpi_bus_add);#endif /*CONFIG_ACPI_BUS*/
drivers/acpi/scan.c renamed from drivers/acpi/scan.c~acpi_core +122 -9
179 lines not on this page · raw message
include/acpi/acpi_drivers.h renamed from include/acpi/acpi_drivers.h~acpi_core +2 -0
@@ -61,12 +61,14 @@ int acpi_pci_link_get_irq (acpi_handle h/* ACPI PCI Interrupt Routing (pci_irq.c) */ int acpi_pci_irq_add_prt (acpi_handle handle,int segment,int bus); +void acpi_pci_irq_del_prt (int segment,int bus);/* ACPI PCI Device Binding (pci_bind.c) */ struct pci_bus ;int acpi_pci_bind (struct acpi_device *device); +int acpi_pci_unbind (struct acpi_device *device);int acpi_pci_bind_root (struct acpi_device *device,struct acpi_pci_id *id,struct pci_bus *bus);/* Arch-defined function to add a bus to the system */
drivers/acpi/pci_irq.c renamed from drivers/acpi/pci_irq.c~acpi_core +39 -3
85 lines not on this page · raw message
drivers/acpi/pci_bind.c renamed from drivers/acpi/pci_bind.c~acpi_core +45 -0
63 lines not on this page · raw message
drivers/acpi/bus.c renamed from drivers/acpi/bus.c~acpi_core +0 -4
@@ -53,10 +53,6 @@ struct proc_dir_entry *acpi_root_dir;Device Management -------------------------------------------------------------------------- */ -extern void acpi_bus_data_handler ( -acpi_handle handle, -u32 function, -void *context); int acpi_bus_get_device ( acpi_handle handle,
_
PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
In reply to Keshavamurthy Anil S---
Name:acpi_core_eject.patch
Status: Tested on 2.6.9-rc2
Depends:acpi_core
Version: applies on 2.6.9-rc2
This patch support /sys/firmware/acpi/eject interface where in the ACPI device say "LSB0" can be ejected by echoing "\_SB.LSB0" > /sys/firmware/acpi/eject
The kernel when it receives an hardware sci eject request it simply passes this to user mode agent and the agent in turn will offline all the child devices and then echo's the ACPI device name onto /sys/firware/acpi/eject file and then the kernel will then actually remove the device.
---
linux-2.6.9-rc2-askeshav/drivers/acpi/scan.c | 141 +++++++++++++++++++++++++++ 1 files changed, 141 insertions(+)
drivers/acpi/scan.c renamed from drivers/acpi/scan.c~acpi_core_eject +141 -0
@@ -2,6 +2,7 @@* scan.c - support for transforming the ACPI namespace into individual objects */ +#include <linux/module.h> #include <linux/init.h> #include <linux/acpi.h>
@@ -291,6 +292,141 @@ end: }/* -------------------------------------------------------------------------- +ACPI hotplug Eject support +-------------------------------------------------------------------------- */ +static ssize_t acpi_eject_store (struct subsystem *subsys,const char *buf,size_t count); +static struct subsys_attribute acpi_eject_attr = +__ATTR (eject,0200 ,NULL ,acpi_eject_store); + +/* +* evaluate _EJ0, detach driver, and remove from ACPI bus +*/ +static int +eject_operation (acpi_handle handle,int lockable) +{ +struct acpi_object_list arg_list; +union acpi_object arg; +acpi_status status =AE_OK ; + +/* +* TBD: evaluate _PS3? +*/ + +if (lockable) { + arg_list.count =1 ; + arg_list.pointer = &arg; + arg.type =ACPI_TYPE_INTEGER ; + arg.integer.value =0 ; +acpi_evaluate_object (handle,"_LCK" , &arg_list,NULL ); + } + + arg_list.count =1 ; + arg_list.pointer = &arg; + arg.type =ACPI_TYPE_INTEGER ; + arg.integer.value =1 ; + +/* +* TBD: _EJD support. +*/ + + status =acpi_evaluate_object (handle,"_EJ0" , &arg_list,NULL ); +if (ACPI_FAILURE (status)) { +return (-ENODEV ); + } + +return (0 ); +} + +static ssize_t +acpi_eject_store (struct subsystem *subsys,const char *buf,size_t count) +{ +acpi_status status; +acpi_handle hlsb; +struct acpi_device *device =NULL ; +int result; +int ret = count; + +char *acpi_name; +char *p; +int islockable; +acpi_object_type type =0 ; + +if (!count) { +return -EINVAL ; + } + + acpi_name =kmalloc (count+1 ,GFP_KERNEL ); +if (!acpi_name) { +return -ENOMEM ; + } + + acpi_name[count] ='\0' ; +strncpy (acpi_name, buf, count); + +for (p = acpi_name+(count-1 ); p >= acpi_name; --p) { +if (isspace (*p)) + *p ='\0' ; +else +break ; + } + + status =acpi_get_handle (NULL , acpi_name, &hlsb); +if (ACPI_FAILURE (status)) { + ret = -ENODEV ; + goto err; + } + + status =acpi_get_type (hlsb, &type); +if (ACPI_FAILURE (status)) { + ret = -ENODEV ; + goto err; + } + + result =acpi_bus_get_device (hlsb, &device); +if (result) { + ret = -ENODEV ; + goto err; + } +#ifndef FORCE_EJECT +if (device->driver ==NULL ) { + ret = -ENODEV ; + goto err; + } +#endif +if (!device->flags.ejectable) { + ret = -ENODEV ; + goto err; + } + + islockable = device->flags.lockable; + +/* +* remove from ACPI bus. +*/ +if (type ==ACPI_BUS_TYPE_PROCESSOR ) +acpi_bus_trim (device,0 ); +else +acpi_bus_trim (device,1 ); + + + result =eject_operation (hlsb, islockable); +if (result) { + ret = -EBUSY ; + } +err: +kfree (acpi_name); +return ret; +} + + +static int __init register_acpi_eject (void ) +{ +subsys_create_file (&acpi_subsys, &acpi_eject_attr); +return 0 ; +} + + +/* -------------------------------------------------------------------------- Performance Management -------------------------------------------------------------------------- */
@@ -1153,6 +1289,11 @@ static int __init acpi_scan_init(void)if (result)acpi_device_unregister (acpi_root,ACPI_BUS_REMOVAL_NORMAL ); +/* +* Register hotplug eject interface +*/ +register_acpi_eject (); + Done:return_VALUE (result); }
_
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 4 lines · Keshavamurthy Anil S
This patch support
/sys/firmware/acpi/ejectinterface where in the ACPI device say "LSB0" can be ejected by echoing "\_SB.LSB0" >/sys/firmware/acpi/eject
I wonder if eject should be an attribute of an individual device and visible only when device can be ejected. Reading from it could show eject level (_EJ0/_EJ3 etc).
Signature · 1 line
Dmitry
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 9 lines · Dmitry Torokhov
Quoted 4 lines · Keshavamurthy Anil S
This patch support
/sys/firmware/acpi/ejectinterface where in the ACPI device say "LSB0" can be ejected by echoing "\_SB.LSB0" >/sys/firmware/acpi/ejectI wonder if eject should be an attribute of an individual device and visible only when device can be ejected. Reading from it could show eject level (_EJ0/_EJ3 etc).
Hi Dmitry,
Today there is really no sysfs representation of acpi devices apart from
the acpi namespace representation. Evaluating acpi namespaces's _EJ0 method won't help, as we need acpi device and all its child devices to be removed as part of the eject.
Also for there is no 1:1 maping of acpi devices to pci devices to consider eject to be part of the pci devices.
Hence the best solution for now is to echo ACPI full path name of the device to be
ejected onto the eject file and the code will make sure that the device supports _EJx method before actuall removing the device.
thanks,
Anil
Quoted 3 lines
Signature · 2 lines
-- Dmitry
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 15 lines · Keshavamurthy Anil S
Quoted 9 lines · Dmitry Torokhov
Quoted 4 lines · Keshavamurthy Anil S
This patch support
/sys/firmware/acpi/ejectinterface where in the ACPI device say "LSB0" can be ejected by echoing "\_SB.LSB0" >/sys/firmware/acpi/ejectI wonder if eject should be an attribute of an individual device and visible only when device can be ejected. Reading from it could show eject level (_EJ0/_EJ3 etc).
Hi Dmitry,
Today there is really no sysfs representation of acpi devices apart from
the acpi namespace representation. Evaluating acpi namespaces's_EJ0method won't help, as we need acpi device and all its child devices to be removed as part of the eject.
Quoted 6 lines
Also for there is no 1:1 maping of acpi devices to pci devices to consider eject to be part of the pci devices.
Hence the best solution for now is to echo ACPI full path name of the device to be
ejected onto the eject file and the code will make sure that the device supports_EJxmethod before actuall removing the device.
Hi Anil,
I obviously failed to deliver my idea :) I meant that I would like add eject attribute (along with maybe status, hid and some others) to kobjects in /sys/firmware/acpi tree.
I also wonder if userspace should traverse tree and emit eject requests for children. While it is OK for user[space]-initiated removal what about surprise removal. My concern that scripts will not be ready for all devices to be suddently gone... Would not it be beter if generic handler for BUS_CHECK was implemented in acpi/bus.c that would add/remove acpi devices and notify userspace via hotplug?
Signature · 1 line
Dmitry
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 7 lines · Dmitry Torokhov
Hi Anil,
I obviously failed to deliver my idea :) I meant that I would like add eject attribute (along with maybe status, hid and some others) to kobjects in
/sys/firmware/acpitree.
Dmitry,
See the patch I just posted to acpi-devel and lkml (Subject:
[PATCH/RFC] exposing ACPI objects in sysfs). It exposes acpi objects as
you describe. Something simple like:
# cat /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/_EJ0
Will call the _EJ0 method on the ACPI device. You can evaluate eject dependencies using the _EJD method.
Alex
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 15 lines · Alex Williamson
Quoted 7 lines · Dmitry Torokhov
Hi Anil,
I obviously failed to deliver my idea :) I meant that I would like add eject attribute (along with maybe status, hid and some others) to kobjects in
/sys/firmware/acpitree.Dmitry,
See the patch I just posted to acpi-devel and lkml (Subject:
[PATCH/RFC] exposing ACPI objects in sysfs). It exposes acpi objects as
you describe. Something simple like:
Quoted 7 lines
# cat /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/_EJ0Will call the
_EJ0method on the ACPI device. You can evaluate eject dependencies using the_EJDmethod.Alex
Alex,
While I think that your patch is very important and should be included (maybe if not as is if somebody has some objections but in some other form) I see it more like developer's tool. I imagined status, HID, eject etc. attributes to be sanitized interface to kernel's data, not necessarily causing re-evaluation.
So it could be like this:
/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/status /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/removable /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/lockable .. /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/eject
And your raw access to the ACPI methods could reside under raw:
/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_STA /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_RNV /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_LCK .. /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_EJ0
Signature · 1 line
Dmitry
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 31 lines · Dmitry Torokhov
Quoted 15 lines · Alex Williamson
Quoted 7 lines · Dmitry Torokhov
Hi Anil,
I obviously failed to deliver my idea :) I meant that I would like add eject attribute (along with maybe status, hid and some others) to kobjects in
/sys/firmware/acpitree.Dmitry,
See the patch I just posted to acpi-devel and lkml (Subject:
[PATCH/RFC] exposing ACPI objects in sysfs). It exposes acpi objects as
you describe. Something simple like:Quoted 7 lines
# cat /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/_EJ0Will call the
_EJ0method on the ACPI device. You can evaluate eject dependencies using the_EJDmethod.Alex
Alex,
While I think that your patch is very important and should be included (maybe if not as is if somebody has some objections but in some other form) I see it more like developer's tool. I imagined status, HID, eject etc. attributes to be sanitized interface to kernel's data, not necessarily causing re-evaluation.
Quoted 7 lines
So it could be like this:
/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/status/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/removable/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/lockable../sys/firmware/acpi/namespace/ACPI/_SB/LSB0/eject
Ha..Now I got it and what you are saying sounds right thing to do. I will invistigate more and will get back to the mailing list hopefully with the patch:)
Quoted 11 lines
And your raw access to the ACPI methods could reside under raw:
/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_STA/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_RNV/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_LCK../sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_EJ0Signature · 1 line
Dmitry
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
In reply to Dmitry TorokhovQuoted 24 lines · Dmitry Torokhov
Quoted 15 lines · Alex Williamson
Quoted 7 lines · Dmitry Torokhov
Hi Anil,
I obviously failed to deliver my idea :) I meant that I would like add eject attribute (along with maybe status, hid and some others) to kobjects in
/sys/firmware/acpitree.Dmitry,
See the patch I just posted to acpi-devel and lkml (Subject:
[PATCH/RFC] exposing ACPI objects in sysfs). It exposes acpi objects as
you describe. Something simple like:Quoted 7 lines
# cat /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/_EJ0Will call the
_EJ0method on the ACPI device. You can evaluate eject dependencies using the_EJDmethod.Alex
Quoted 7 lines
Alex,
While I think that your patch is very important and should be included (maybe if not as is if somebody has some objections but in some other form) I see it more like developer's tool. I imagined status, HID, eject etc. attributes to be sanitized interface to kernel's data, not necessarily causing re-evaluation.
Dmitry,
I imagined the sanitized interfaces would be provided via a userspace
library, similar to how lspci provides a clean interface to all of the PCI data. An "lsacpi" tool could extract the information into something more like you suggest. If you have objects exposed as human readable/writable files, I think you'll quickly end up with a _STA driver, _HID driver, _CID driver, _ADR driver, _UID driver, _EJx driver, etc, etc, etc... I don't think we want that kind of bloat in the kernel (that's what userspace is for ;^). Providing a solid, direct interface to ACPI methods in the kernel seems like the most flexible, powerful interface IMHO. Thanks,
Alex
Quoted 15 lines
So it could be like this:
/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/status/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/removable/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/lockable../sys/firmware/acpi/namespace/ACPI/_SB/LSB0/ejectAnd your raw access to the ACPI methods could reside under raw:
/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_STA/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_RNV/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_LCK../sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_EJ0
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 12 lines · Alex Williamson
Dmitry,
I imagined the sanitized interfaces would be provided via a userspace library, similar to how lspci provides a clean interface to all of the PCI data. An "lsacpi" tool could extract the information into something more like you suggest. If you have objects exposed as human readable/writable files, I think you'll quickly end up with a
_STAdriver,_HIDdriver,_CIDdriver,_ADRdriver,_UIDdriver,_EJxdriver, etc, etc, etc... I don't think we want that kind of bloat in the kernel (that's what userspace is for ;^). Providing a solid, direct interface to ACPI methods in the kernel seems like the most flexible, powerful interface IMHO.
Hmm, I do not quite agree. Except for "eject" being writeable to initiate eject action the rest of the attributes would reflect kernel's view of the device state and not re-evaluated when userspace references them. Monitoring (or rather reacting to various events, like DEVICE_CHECK and BUS_CHECK) and updating devices' statuses and other data is responsibility of the core ACPI system. If system administrator is forced to manually (via libacpi or sysfs) query device status to "kick" the device into working state I'd consider it a bug, would'nt you agree?
I see that in your other mail you mention _CRS parsing and chipset discovery. I think that if you had an ability to just retrieve raw ACPI data from the system that would suffice. In other words during normal operations there is no need for "active" ACPI methods (such as _WAK, _S4, etc) to be available from userspace. And just exporting raw data solves problem of bloating kernel with parsing of vendor-specific data. I wonder if any of these methods need arguments to run - if not then we would not need any adjustments to sysfs opeen/close methods.
I am not saying that we should chose one method or another. I think they both can co-exist, as they can be used for diffectent purposes - the raw ACPI access can affect state of the box while the sanitized attributes present kernel's view and can be used to verify results of some action from kernel's POV.
Signature · 5 lines
Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
In reply to Dmitry TorokhovQuoted 23 lines · Dmitry Torokhov
Quoted 15 lines · Keshavamurthy Anil S
Quoted 9 lines · Dmitry Torokhov
Quoted 4 lines · Keshavamurthy Anil S
This patch support
/sys/firmware/acpi/ejectinterface where in the ACPI device say "LSB0" can be ejected by echoing "\_SB.LSB0" >/sys/firmware/acpi/ejectI wonder if eject should be an attribute of an individual device and visible only when device can be ejected. Reading from it could show eject level (_EJ0/_EJ3 etc).
Hi Dmitry,
Today there is really no sysfs representation of acpi devices apart from
the acpi namespace representation. Evaluating acpi namespaces's_EJ0method won't help, as we need acpi device and all its child devices to be removed as part of the eject.Quoted 6 lines
Also for there is no 1:1 maping of acpi devices to pci devices to consider eject to be part of the pci devices.
Hence the best solution for now is to echo ACPI full path name of the device to be
ejected onto the eject file and the code will make sure that the device supports_EJxmethod before actuall removing the device.
Quoted 5 lines
Hi Anil,
I obviously failed to deliver my idea :) I meant that I would like add eject attribute (along with maybe status, hid and some others) to kobjects in
/sys/firmware/acpitree.
I got this one and as I have said I will come up with the path soon:)
Quoted 7 lines
I also wonder if userspace should traverse tree and emit eject requests for children. While it is OK for user[space]-initiated removal what about surprise removal. My concern that scripts will not be ready for all devices to be suddently gone... Would not it be beter if generic handler for
BUS_CHECKwas implemented inacpi/bus.cthat would add/remove acpi devices and notify userspace via hotplug?
Can you please clarify my concern here.
Currently I am handling both the surprise removal and the eject request in the same way, i,e send the notification to the userland and the usermode agent scripts is responsible for offlining of all the devices and then echoing onto eject file.
My worry is if we implement a generic handler for BUS_CHECK, then what would you do if the device fails to remove, i.e what action to take if the device remove fails?
Thanks,
Anil
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 4 lines · Keshavamurthy Anil S
Currently I am handling both the surprise removal and the eject request in the same way, i,e send the notification to the userland and the usermode agent scripts is responsible for offlining of all the devices and then echoing onto eject file.
I actually think that on the highest level we should treat controlled and surprise ejects differently. With controlled ejects the system (kernel + userspace) can abort the sequence if something goes wrong while with surprise eject the device is physically gone. Even if driver refuses to detach or we have partition still mounted or something else if physical device is gone we don't have any choice except for trimming the tree and doing whatever we need to do.
Quoted 3 lines
My worry is if we implement a generic handler for
BUS_CHECK, then what would you do if the device fails to remove, i.e what action to take if the device remove fails?
It could depend on parent's status. If parent is gone (surprise removal) we will trim. If it is controlled removal and driver does not let device go we could abort eject.
Or we could always trim and offload the responsibility of having the system in ready-to-eject state to the userspace. I.e. it should not write into "eject" unless everything is unmounted/shut down/disconnected.
I am a bit light on implementation details though ;)
Signature · 1 line
Dmitry
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 6 lines · Dmitry Torokhov
Quoted 4 lines · Keshavamurthy Anil S
Currently I am handling both the surprise removal and the eject request in the same way, i,e send the notification to the userland and the usermode agent scripts is responsible for offlining of all the devices and then echoing onto eject file.
Quoted 7 lines
I actually think that on the highest level we should treat controlled and surprise ejects differently. With controlled ejects the system (kernel + userspace) can abort the sequence if something goes wrong while with surprise eject the device is physically gone. Even if driver refuses to detach or we have partition still mounted or something else if physical device is gone we don't have any choice except for trimming the tree and doing whatever we need to do.
I agree, but when dealing with devices like CPU and Memory, not sure how the rest of the Operating System handles surprise removal. For now I will go ahead and add a PRINTK saying that BUS_CHECK(surprise removal request) was received in the ACPI Processor and in the container driver, and when we hit that printk on a real hardware, I believe it would be the right time then to see how the OS behaves and do the right code then. For Now I will just go ahead and add a PRINTK.
Let me know if this step by step approach is okay to you.
thanks,
Anil
Re: [Lhns-devel] Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 11 lines · Keshavamurthy Anil S
Quoted 9 lines · Dmitry Torokhov
On Monday 20 September 2004 08:38 pm, Keshavamurthy Anil S wrote:
I actually think that on the highest level we should treat controlled and surprise ejects differently. With controlled ejects the system (kernel + userspace) can abort the sequence if something goes wrong while with surprise eject the device is physically gone. Even if driver refuses to detach or we have partition still mounted or something else if physical device is gone we don't have any choice except for trimming the tree and doing whatever we need to do.
Quoted 2 lines
I agree, but when dealing with devices like CPU and Memory, not sure how the rest of the Operating System handles surprise removal.
If by "surprise removal" you mean an Itanium CPU or Memory no longer are accessable by the rest of the hardware, the result will be fatal MCA. For example, if an Itanum CPU tried to load from Memory that no longer exists, the load will time out and the CPU will generate a fatal MCA. It may (or may not) be possible to enhance the MCA/linux error handling code to handle this situation, but the current code does not.
Quoted 10 lines
For now I will go ahead and
add a PRINTK saying thatBUS_CHECK(surprise removal request)was received in the ACPI Processor and in the container driver, and when we hit that printk on a real hardware, I believe it would be the right time then to see how the OS behaves and do the right code then. For Now I will just go ahead and add a PRINTK.Let me know if this step by step approach is okay to you.
thanks,
Anil
Signature · 2 lines
Russ Anderson, OS RAS/Partitioning Project Lead SGI - Silicon Graphics Inc [email protected]
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
In reply to Keshavamurthy Anil SQuoted 15 lines · Keshavamurthy Anil S
Quoted 6 lines · Dmitry Torokhov
Quoted 4 lines · Keshavamurthy Anil S
Currently I am handling both the surprise removal and the eject request in the same way, i,e send the notification to the userland and the usermode agent scripts is responsible for offlining of all the devices and then echoing onto eject file.
Quoted 7 lines
I actually think that on the highest level we should treat controlled and surprise ejects differently. With controlled ejects the system (kernel + userspace) can abort the sequence if something goes wrong while with surprise eject the device is physically gone. Even if driver refuses to detach or we have partition still mounted or something else if physical device is gone we don't have any choice except for trimming the tree and doing whatever we need to do.
Quoted 7 lines
I agree, but when dealing with devices like CPU and Memory, not sure how the rest of the Operating System handles surprise removal. For now I will go ahead and add a PRINTK saying that
BUS_CHECK(surprise removal request)was received in the ACPI Processor and in the container driver, and when we hit that printk on a real hardware, I believe it would be the right time then to see how the OS behaves and do the right code then. For Now I will just go ahead and add a PRINTK.
Heh, I really don't expect the kernel to survive if somebody just yanks out a CPU without a warning, especially if the CPU is the last one :) I hand in mind devices like my port replicator that only has an additional network card and could survive surprise removal.
Quoted 1 line
Let me know if this step by step approach is okay to you.
It sure is, we can always adjust the process down the road.
Thank you for your work!
Signature · 1 line
Dmitry
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
In reply to Dmitry TorokhovQuoted 5 lines · Dmitry Torokhov
Hi Anil,
I obviously failed to deliver my idea :) I meant that I would like add eject attribute (along with maybe status, hid and some others) to kobjects in
/sys/firmware/acpitree.
Here the modified patch based on the your feedback. Now I am creating eject attribute to the acpi kobjects in /sys/firmware/acpi.
---
Name:acpi_core_eject.patch
Status: Tested on 2.6.9-rc2
Depends:acpi_core
Version: applies on 2.6.9-rc2
The kernel when it receives an hardware sci eject request it simply passes this to user mode agent and the agent in turn will offline all the child devices and then echo's 1 onto the eject file for that acpi device.
This patch provides the sysfs "eject" interface for the user mode agent to notify the core acpi so that the core acpi can trim its bus which causes .remove function to be called for all child devices.
For example for LSB0 which is an ejectable device, we will see /sys/firmware/acpi/namespace/ACPI/_SB/LSB/eject.
---
linux-2.6.9-rc2-askeshav/drivers/acpi/scan.c | 153 +++++++++++++++++++++++++++ 1 files changed, 153 insertions(+)
drivers/acpi/scan.c renamed from drivers/acpi/scan.c~acpi_core_eject +153 -0
@@ -2,6 +2,7 @@* scan.c - support for transforming the ACPI namespace into individual objects */ +#include <linux/module.h> #include <linux/init.h> #include <linux/acpi.h>
@@ -34,7 +35,49 @@ static void acpi_device_release(struct kkfree (dev); } +struct acpi_device_attribute { +struct attribute attr; +ssize_t (*show)(struct acpi_device *,char *); +ssize_t (*store)(struct acpi_device *,const char *,size_t ); +}; + +typedef void acpi_device_sysfs_files (struct kobject *, +const struct attribute *); + +static void setup_sys_fs_device_files (struct acpi_device *dev, +acpi_device_sysfs_files *func); + +#define create_sysfs_device_files (dev) \ + setup_sys_fs_device_files(dev, (acpi_device_sysfs_files *)&sysfs_create_file) +#define remove_sysfs_device_files (dev) \ + setup_sys_fs_device_files(dev, (acpi_device_sysfs_files *)&sysfs_remove_file) + + +#define to_acpi_device (n) container_of(n, struct acpi_device, kobj) +#define to_handle_attr (n) container_of(n, struct acpi_device_attribute, attr); + +static ssize_t acpi_device_attr_show (struct kobject *kobj, +struct attribute *attr,char *buf) +{ +struct acpi_device *device =to_acpi_device (kobj); +struct acpi_device_attribute *attribute =to_handle_attr (attr); +return attribute->show ? attribute->show (device, buf) :0 ; +} +static ssize_t acpi_device_attr_store (struct kobject *kobj, +struct attribute *attr,const char *buf,size_t len) +{ +struct acpi_device *device =to_acpi_device (kobj); +struct acpi_device_attribute *attribute =to_handle_attr (attr); +return attribute->store ? attribute->store (device, buf, len) : len; +} + +static struct sysfs_ops acpi_device_sysfs_ops = { + .show = acpi_device_attr_show, + .store = acpi_device_attr_store, +}; +static struct kobj_type ktype_acpi_ns = { + .sysfs_ops = &acpi_device_sysfs_ops, .release = acpi_device_release, };
@@ -76,6 +119,7 @@ static void acpi_device_register(struct device->kobj.ktype = &ktype_acpi_ns; device->kobj.kset = &acpi_namespace_kset;kobject_add (&device->kobj); +create_sysfs_device_files (device); } static int
@@ -95,6 +139,7 @@ acpi_device_unregister (spin_unlock (&acpi_device_lock);acpi_detach_data (device->handle, acpi_bus_data_handler); +remove_sysfs_device_files (device);kobject_unregister (&device->kobj);return 0 ; }
@@ -291,6 +336,114 @@ end: }/* -------------------------------------------------------------------------- +ACPI hotplug sysfs device file support +-------------------------------------------------------------------------- */ +static ssize_t acpi_eject_store (struct acpi_device *device, +const char *buf,size_t count); + +#define ACPI_DEVICE_ATTR (_name,_mode,_show,_store) \ +static struct acpi_device_attribute acpi_device_attr_##_name = \ + __ATTR(_name, _mode, _show, _store) + +ACPI_DEVICE_ATTR (eject,0200 ,NULL , acpi_eject_store); + +/** +* setup_sys_fs_device_files - sets up the device files under device namespace +* @@dev: acpi_device object +* @@func: function pointer to create or destroy the device file +*/ +static void +setup_sys_fs_device_files ( +struct acpi_device *dev, +acpi_device_sysfs_files *func) +{ +if (dev->flags.ejectable ==1 ) + (*(func))(&dev->kobj,&acpi_device_attr_eject.attr); +} + +static int +acpi_eject_operation (acpi_handle handle,int lockable) +{ +struct acpi_object_list arg_list; +union acpi_object arg; +acpi_status status =AE_OK ; + +/* +* TBD: evaluate _PS3? +*/ + +if (lockable) { + arg_list.count =1 ; + arg_list.pointer = &arg; + arg.type =ACPI_TYPE_INTEGER ; + arg.integer.value =0 ; +acpi_evaluate_object (handle,"_LCK" , &arg_list,NULL ); + } + + arg_list.count =1 ; + arg_list.pointer = &arg; + arg.type =ACPI_TYPE_INTEGER ; + arg.integer.value =1 ; + +/* +* TBD: _EJD support. +*/ + + status =acpi_evaluate_object (handle,"_EJ0" , &arg_list,NULL ); +if (ACPI_FAILURE (status)) { +return (-ENODEV ); + } + +return (0 ); +} + + +static ssize_t +acpi_eject_store (struct acpi_device *device,const char *buf,size_t count) +{ +int result; +int ret = count; +int islockable; +acpi_status status; +acpi_handle handle; +acpi_object_type type =0 ; + +if ((!count) || (buf[0 ] !='1' )) { +return -EINVAL ; + } + +#ifndef FORCE_EJECT +if (device->driver ==NULL ) { + ret = -ENODEV ; + goto err; + } +#endif + status =acpi_get_type (device->handle, &type); +if (ACPI_FAILURE (status) || (!device->flags.ejectable) ) { + ret = -ENODEV ; + goto err; + } + + islockable = device->flags.lockable; + handle = device->handle; + +if (type ==ACPI_TYPE_PROCESSOR ) + result =acpi_bus_trim (device,0 ); +else + result =acpi_bus_trim (device,1 ); + +if (!result) + result =acpi_eject_operation (handle, islockable); + +if (result) { + ret = -EBUSY ; + } +err: +return ret; +} + + +/* -------------------------------------------------------------------------- Performance Management -------------------------------------------------------------------------- */
_
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
drivers/acpi/scan.c static void acpi_device_release(struct k · line 53
Quoted 10 lines · Keshavamurthy Anil S
drivers/acpi/scan.c renamed from drivers/acpi/scan.c~acpi_core_eject +10
-0+typedef void acpi_device_sysfs_files (struct kobject *, + const struct attribute *); + +static void setup_sys_fs_device_files (struct acpi_device *dev, + acpi_device_sysfs_files *func); + +#define create_sysfs_device_files (dev) \ + setup_sys_fs_device_files(dev, (acpi_device_sysfs_files *)&sysfs_create_file) +#define remove_sysfs_device_files (dev) \ + setup_sys_fs_device_files(dev, (acpi_device_sysfs_files *)&sysfs_remove_file)
Hi Anil,
It looks very nice except for the part above. I am really confused what the purpose of this code is... It looks like it just complicates things?
Signature · 5 lines
Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 15 lines · Dmitry Torokhov
drivers/acpi/scan.c static void acpi_device_release(struct k · line 53
Quoted 10 lines · Keshavamurthy Anil S
drivers/acpi/scan.c renamed from drivers/acpi/scan.c~acpi_core_eject +10
-0+typedef void acpi_device_sysfs_files (struct kobject *, + const struct attribute *); + +static void setup_sys_fs_device_files (struct acpi_device *dev, + acpi_device_sysfs_files *func); + +#define create_sysfs_device_files (dev) \ + setup_sys_fs_device_files(dev, (acpi_device_sysfs_files *)&sysfs_create_file) +#define remove_sysfs_device_files (dev) \ + setup_sys_fs_device_files(dev, (acpi_device_sysfs_files *)&sysfs_remove_file)Hi Anil,
Quoted 2 lines
It looks very nice except for the part above. I am really confused what the purpose of this code is... It looks like it just complicates things?
Hi Dmitry,
I just wanted to have a single function i.e setup_sys_fs_device_files() for both
creating and removing sysfs files. So I have #defined create_sysfs_device_files() and remove_sysfs_device_files() and one of the arguments to the setup_sys_fs_device_files() is a function pointer, i.e for one it takes sysfs_create_file and for other it takes sysfs_remove_file.
Having single function for creating and removing sysfs files make it easy from the maintaince perspective, as oppose to remember to code for remove as well when one adds the new file.
thanks,
Anil
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 2 lines · Keshavamurthy Anil S
I just wanted to have a single function i.e
setup_sys_fs_device_files()for both creating and removing sysfs files.
Ah, I see... Makes sense, especially when there is additional logic involved in creating some of the attributes, which is the case with ACPI.
Signature · 5 lines
Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
In reply to Keshavamurthy Anil SQuoted 7 lines · On Mon, 20 Sep 2004 09:35:33 -0700 Keshavamurthy Anil S wrote:
---
Name:acpi_core_eject.patch
Status: Tested on 2.6.9-rc2Signed-off-by Anil S Keshavamurthy <[email protected]>Depends:acpi_core
Version: applies on 2.6.9-rc2
Quoted 8 lines
This patch support
/sys/firmware/acpi/ejectinterface where in the ACPI device say "LSB0" can be ejected by echoing "\_SB.LSB0" >/sys/firmware/acpi/ejectThe kernel when it receives an hardware sci eject request it simply passes this to user mode agent and the agent in turn will offline all the child devices and then echo's the ACPI device name onto
/sys/firware/acpi/ejectfile and then the kernel will then actually remove the device.
In acpi_eject_store(), eject_operation() is called regardless of the result of acpi_bus_trim(). I think that eject_operation() should be called only when acpi_bus_trim() returns success. Otherwise, a device stil being online will be ejected forcibly.
Two steps might be needed to do this.
1. Modify acpi_bus_trim() to return success only when all the acpi_bus_remove() are done successfully.
2. Modify acpi_eject_store() to see the result and call eject_operation() only when the result is success.
Here is a patch just to show what I have in mind. It is still based on the recursion, so please fix it as appropriate ;)
Thanks,
Keiichiro Tokunaga
Name: acpi_core_eject_fix.patch
Status: Tested on 2.6.9-rc2
---
linux-2.6.9-rc2-fix-kei/drivers/acpi/scan.c | 26 +++++++++++++++--------- linux-2.6.9-rc2-fix-kei/include/acpi/acpi_bus.h | 2 - 2 files changed, 18 insertions(+), 10 deletions(-)
drivers/acpi/scan.c renamed from drivers/acpi/scan.c~acpi_core_eject_fix +17 -9
@@ -404,11 +404,14 @@ acpi_eject_store(struct subsystem *subsy* remove from ACPI bus. */ if (type ==ACPI_BUS_TYPE_PROCESSOR ) -acpi_bus_trim (device,0 ); + result =acpi_bus_trim (device,0 );else -acpi_bus_trim (device,1 ); + result =acpi_bus_trim (device,1 ); - +if (result) { + ret = -EBUSY ; + goto err; + } result =eject_operation (hlsb, islockable);if (result) { ret = -EBUSY ;
@@ -1203,7 +1206,7 @@ int acpi_bus_scan (struct acpi_device *sreturn_VALUE (0 ); } -void +int acpi_bus_trim (struct acpi_device *start,int rmdevice) {
@@ -1212,25 +1215,30 @@ acpi_bus_trim(struct acpi_device *start,struct acpi_device *child =NULL ;acpi_handle phandle =0 ;acpi_handle chandle =0 ; - +int err =0 ; parent = start; phandle = start->handle;/* * NOTE: must be freed in a depth-first manner. */ -while (1 ) { +while (1 ) { status =acpi_get_next_object (ACPI_TYPE_ANY , phandle, chandle, &chandle); -if (ACPI_SUCCESS (status) && chandle !=NULL ) { +if (ACPI_SUCCESS (status) && chandle !=NULL ) {if (acpi_bus_get_device (chandle, &child) ==0 ) -acpi_bus_trim (child,1 ); +if (acpi_bus_trim (child,1 )) + err =1 ; }else {/* this is a leaf */ -acpi_bus_remove (parent, rmdevice); +if (!err) { +if (acpi_bus_remove (parent, rmdevice)) + err =1 ; + }break ; } } +return err; } static int
include/acpi/acpi_bus.h renamed from include/acpi/acpi_bus.h~acpi_core_eject_fix +1 -1
@@ -325,7 +325,7 @@ int acpi_bus_receive_event (struct acpi_int acpi_bus_register_driver (struct acpi_driver *driver);int acpi_bus_unregister_driver (struct acpi_driver *driver);int acpi_bus_scan (struct acpi_device *start); -void acpi_bus_trim (struct acpi_device *start,int rmdevice); +int acpi_bus_trim (struct acpi_device *start,int rmdevice);int acpi_bus_add (struct acpi_device **child,struct acpi_device *parent,acpi_handle handle,int type);
_
Re: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
Quoted 11 lines
In
acpi_eject_store(),eject_operation()is called regardless of the result ofacpi_bus_trim(). I think thateject_operation()should be called only whenacpi_bus_trim()returns success. Otherwise, a device stil being online will be ejected forcibly.Two steps might be needed to do this.
1. Modify
acpi_bus_trim()to return success only when all theacpi_bus_remove()are done successfully.
2. Modifyacpi_eject_store()to see the result and calleject_operation()only when the result is success.
Hi Kei-san,
Your idea and the patch both looks good to me.
Thanks for eye balling the code and detecting the corner cases like this.
Quoted 3 lines
Here is a patch just to show what I have in mind. It is still based on the recursion, so please fix it as appropriate ;)
I will merge this with my non-recursion version of the patch and post it ASAP.
thanks,
Anil
PATCH-ACPI based CPU hotplug[3/6]-Mapping lsapic to cpu
In reply to Keshavamurthy Anil S---
Name:acpi_hotplug_arch.patch
Status: Tested on 2.6.9-rc2
Depends:
Version: applies on 2.6.9-rc2
Description:
This patch provides the architecture specifice support for mapping lsapic to cpu array. Currently this supports just IA64. Support for IA32 and x86_64 is in progress
---
linux-2.6.9-rc2-askeshav/arch/i386/kernel/acpi/boot.c | 22 +++ linux-2.6.9-rc2-askeshav/arch/ia64/kernel/acpi.c | 127 +++++++++++++++++- linux-2.6.9-rc2-askeshav/include/linux/acpi.h | 6 3 files changed, 153 insertions(+), 2 deletions(-)
include/linux/acpi.h renamed from include/linux/acpi.h~acpi_hotplug_arch +6 -0
@@ -396,6 +396,12 @@ void acpi_numa_processor_affinity_init (void acpi_numa_memory_affinity_init (struct acpi_table_memory_affinity *ma);void acpi_numa_arch_fixup (void ); +#ifdef CONFIG_ACPI_HOTPLUG_CPU +/* Arch dependent functions for cpu hotplug support */ +int acpi_map_lsapic (acpi_handle handle,int *pcpu); +int acpi_unmap_lsapic (int cpu); +#endif /* CONFIG_ACPI_HOTPLUG_CPU */ +extern int acpi_mp_config;extern u32 pci_mmcfg_base_addr;
arch/ia64/kernel/acpi.c renamed from arch/ia64/kernel/acpi.c~acpi_hotplug_arch +125 -2
140 lines not on this page · raw message
arch/i386/kernel/acpi/boot.c renamed from arch/i386/kernel/acpi/boot.c~acpi_hotplug_arch +22 -0
@@ -478,6 +478,28 @@ unsigned int acpi_register_gsi(u32 gsi, }EXPORT_SYMBOL (acpi_register_gsi); +/* +* ACPI based hotplug support for CPU +*/ +#ifdef CONFIG_ACPI_HOTPLUG_CPU +int +acpi_map_lsapic (acpi_handle handle,int *pcpu) +{ +/* TBD */ +return -EINVAL ; +} +EXPORT_SYMBOL (acpi_map_lsapic); + + +int +acpi_unmap_lsapic (int cpu) +{ +/* TBD */ +return -EINVAL ; +} +EXPORT_SYMBOL (acpi_unmap_lsapic); +#endif /* CONFIG_ACPI_HOTPLUG_CPU */ + static unsigned long __init acpi_scan_rsdp ( unsigned long start,
_
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
Re: [ACPI] PATCH-ACPI based CPU hotplug[3/6]-Mapping lsapic to cpu
Quoted 10 lines · On Mon, 20 Sep 2004 09:38:19 -0700 Keshavamurthy Anil S wrote:
---
Name:acpi_hotplug_arch.patch
Status: Tested on 2.6.9-rc2Signed-off-by Anil S Keshavamurthy <[email protected]>Depends:
Version: applies on 2.6.9-rc2
Description:
This patch provides the architecture specifice support for mapping lsapic to cpu array. Currently this supports just IA64. Support for IA32 andx86_64is in progress
---
Here is a small fix.
Thanks,
Keiichiro Tokunaga
Name: pxm_to_nid_map_fix.patch
Status: Tested on 2.6.9-rc2
Description:
Change an attribute of pxm_to_nid_map[] from __initdata to __devinitdata.
---
linux-2.6.9-rc2-fix-kei/include/asm-ia64/acpi.h | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-)
include/asm-ia64/acpi.h renamed from include/asm-ia64/acpi.h~pxm_to_nid_map_fix +1 -1
@@ -101,7 +101,7 @@ int acpi_gsi_to_irq (u32 gsi, unsigned i#ifdef CONFIG_ACPI_NUMA /* Proximity bitmap length; _PXM is at most 255 (8 bit)*/ #define MAX_PXM_DOMAINS (256) -extern int __initdata pxm_to_nid_map[MAX_PXM_DOMAINS ]; +extern int __devinitdata pxm_to_nid_map[MAX_PXM_DOMAINS ];extern int __initdata nid_to_pxm_map[MAX_NUMNODES ];#endif
_
Re: [ACPI] PATCH-ACPI based CPU hotplug[3/6]-Mapping lsapic to cpu
Quoted 18 lines · Keiichiro Tokunaga
Quoted 10 lines · On Mon, 20 Sep 2004 09:38:19 -0700 Keshavamurthy Anil S wrote:
---
Name:acpi_hotplug_arch.patch
Status: Tested on 2.6.9-rc2Signed-off-by Anil S Keshavamurthy <[email protected]>Depends:
Version: applies on 2.6.9-rc2
Description:
This patch provides the architecture specifice support for mapping lsapic to cpu array. Currently this supports just IA64. Support for IA32 andx86_64is in progress
---Here is a small fix.
Thanks,
Keiichiro Tokunaga
Quoted 5 lines
Name: pxm_to_nid_map_fix.patch
Status: Tested on 2.6.9-rc2Signed-off-by Keiichiro Tokunaga <[email protected]>Description:
Change an attribute of pxm_to_nid_map[] from__initdatato__devinitdata.
good catch:)
thanks,
Anil
Re: [ACPI] PATCH-ACPI based CPU hotplug[3/6]-Mapping lsapic to cpu
In reply to Keshavamurthy Anil SQuoted 10 lines · On Mon, 20 Sep 2004 09:38:19 -0700 Keshavamurthy Anil S wrote:
---
Name:acpi_hotplug_arch.patch
Status: Tested on 2.6.9-rc2Signed-off-by Anil S Keshavamurthy <[email protected]>Depends:
Version: applies on 2.6.9-rc2
Description:
This patch provides the architecture specifice support for mapping lsapic to cpu array. Currently this supports just IA64. Support for IA32 andx86_64is in progress
---
I would like to suggest introducing a new function 'acpi_get_pxm()' since other drivers might need it in the future. Acutally, ACPI container hotplug will be use it soon.
Here is a patch creating the function.
Thanks,
Keiichiro Tokunaga
Name: acpi_pxm_support.patch
Status: 2.6.9-rc2
Description:
Introduce acpi_get_pxm().
---
linux-2.6.9-rc2-fix-kei/drivers/acpi/numa.c | 22 +++++++++++++++++++++- linux-2.6.9-rc2-fix-kei/include/linux/acpi.h | 8 ++++++++ 2 files changed, 29 insertions(+), 1 deletion(-)
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_pxm_support +21 -1
@@ -22,7 +22,7 @@* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * */ - +#include <linux/module.h> #include <linux/config.h> #include <linux/init.h> #include <linux/kernel.h>
@@ -195,3 +195,23 @@ acpi_numa_init()acpi_numa_arch_fixup ();return 0 ; } + +int +acpi_get_pxm (acpi_handle h) +{ +unsigned long pxm=-1 ; +acpi_status status; +acpi_handle handle ; +acpi_handle phandle = h; + +do { + handle = phandle; + status =acpi_evaluate_integer (handle,"_PXM" ,NULL ,&pxm); +if (ACPI_SUCCESS (status)) { +return (int )pxm; + } + status =acpi_get_parent (handle,&phandle); + }while (ACPI_SUCCESS (status) ); +return -1 ; +} +EXPORT_SYMBOL (acpi_get_pxm);
include/linux/acpi.h renamed from include/linux/acpi.h~acpi_pxm_support +8 -0
@@ -477,4 +477,12 @@ static inline int acpi_blacklisted(void)#endif /*!CONFIG_ACPI_INTERPRETER*/ +#ifdef CONFIG_ACPI_NUMA +int acpi_get_pxm (acpi_handle handle); +#else +static inline int acpi_get_pxm (acpi_handle hanle) +{ +return 0 ; +} +#endif #endif /*_LINUX_ACPI_H*/
_
Re: [ACPI] PATCH-ACPI based CPU hotplug[3/6]-Mapping lsapic to cpu
Quoted 12 lines · On Wed, 22 Sep 2004 22:15:38 +0900 Keiichiro Tokunaga wrote:
Quoted 10 lines · On Mon, 20 Sep 2004 09:38:19 -0700 Keshavamurthy Anil S wrote:
---
Name:acpi_hotplug_arch.patch
Status: Tested on 2.6.9-rc2Signed-off-by Anil S Keshavamurthy <[email protected]>Depends:
Version: applies on 2.6.9-rc2
Description:
This patch provides the architecture specifice support for mapping lsapic to cpu array. Currently this supports just IA64. Support for IA32 andx86_64is in progress
---
Quoted 3 lines
I would like to suggest introducing a new function '
acpi_get_pxm()' since other drivers might need it in the future. Acutally, ACPI container hotplug will be use it soon.
I have made a patch to modify your code to use acpi_get_pxm() that I just posted earlier. I hope it does not break your code:) What do you think of it?
Thanks,
Keiichiro Tokunaga
Name: acpi_cpu_pxm_fix.patch
Status: Tested on 2.6.9-rc2
Description:
Modify acpi_map_cpu2node() to use acpi_get_pxm().
---
linux-2.6.9-rc2-fix-kei/arch/ia64/kernel/acpi.c | 31 +++++------------------- 1 files changed, 7 insertions(+), 24 deletions(-)
arch/ia64/kernel/acpi.c renamed from arch/ia64/kernel/acpi.c~acpi_cpu_pxm_fix +7 -24
@@ -659,36 +659,20 @@ int acpi_map_cpu2node(acpi_handle handle, int cpu, long physid) { #ifdef CONFIG_ACPI_NUMA - int pxm_id = 0; -union acpi_object *obj; -struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER ,NULL }; + int pxm_id; -if (ACPI_FAILURE (acpi_evaluate_object (handle,"_PXM" ,NULL , &buffer))) - goto pxm_id_0; + pxm_id =acpi_get_pxm (handle); -if ((!buffer.length) || (!buffer.pointer)) - goto pxm_id_0; - - obj = buffer.pointer; -if (obj->type !=ACPI_TYPE_INTEGER ) { -acpi_os_free (buffer.pointer); - goto pxm_id_0; - } - - pxm_id = obj->integer.value; - -pxm_id_0:/* * Assuming that the container driver would have set the proximity * domain and would have initialized pxm_to_nid_map[pxm_id] && pxm_flag */ -/* Return Error if proximity domain is not set */ -if (!pxm_bit_test (pxm_id)) -return -EINVAL ; - node_cpuid[cpu].phys_id = physid; - node_cpuid[cpu].nid = pxm_to_nid_map[pxm_id]; +if (pxm_id <0 ) + node_cpuid[cpu].nid =0 ; +else + node_cpuid[cpu].nid = pxm_to_nid_map[pxm_id];#endif return (0 );
@@ -737,8 +721,7 @@ acpi_map_lsapic(acpi_handle handle, intif (cpu >=NR_CPUS )return -EINVAL ; -if (ACPI_FAILURE (acpi_map_cpu2node (handle, cpu, physid))) -return -ENODEV ; +acpi_map_cpu2node (handle, cpu, physid);cpu_set (cpu, cpu_present_map); ia64_cpu_to_sapicid[cpu] = physid;
_
Re: [ACPI] PATCH-ACPI based CPU hotplug[3/6]-Mapping lsapic to cpu
In reply to Keiichiro TokunagaQuoted 7 lines · Keiichiro Tokunaga
I would like to suggest introducing a new function '
acpi_get_pxm()' since other drivers might need it in the future. Acutally, ACPI container hotplug will be use it soon.Here is a patch creating the function.
Nice, I have a couple I/O locality patches that could be simplified
with this function.
include/linux/acpi.h static inline int acpi_blacklisted(void) · line 483
Quoted 4 lines
include/linux/acpi.h renamed from include/linux/acpi.h~acpi_pxm_support +4
-0+#ifdef CONFIG_ACPI_NUMA +int acpi_get_pxm (acpi_handle handle); +#else +static inline int acpi_get_pxm (acpi_handle hanle)
Trivial typo here ---> ^^^^^ handle
Alex
Signature · 1 line
Alex Williamson HP Linux & Open Source Lab
Re: [ACPI] PATCH-ACPI based CPU hotplug[3/6]-Mapping lsapic to cpu
Quoted 9 lines · Alex Williamson
Quoted 7 lines · Keiichiro Tokunaga
I would like to suggest introducing a new function '
acpi_get_pxm()' since other drivers might need it in the future. Acutally, ACPI container hotplug will be using it soon.Here is a patch creating the function.
Quoted 8 lines
Nice, I have a couple I/O locality patches that could be simplified
with this function.Review
Quoted 4 lines
(quoted diff) +4
-0+#ifdef CONFIG_ACPI_NUMA +int acpi_get_pxm(acpi_handle handle); +#else +static inline int acpi_get_pxm(acpi_handle hanle)Trivial typo here ---> ^^^^^ handle
Oh, good catch:)
Thanks!
Keiichiro Tokunaga
Name: acpi_pxm_support.patch
Status: 2.6.9-rc2
Description:
Introduce acpi_get_pxm(). The code has been refreshed a little bit from the first version.
---
linux-2.6.9-rc2-fix-kei/drivers/acpi/numa.c | 21 ++++++++++++++++++++- linux-2.6.9-rc2-fix-kei/include/linux/acpi.h | 8 ++++++++ 2 files changed, 28 insertions(+), 1 deletion(-)
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_pxm_support +20 -1
@@ -22,7 +22,7 @@* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * */ - +#include <linux/module.h> #include <linux/config.h> #include <linux/init.h> #include <linux/kernel.h>
@@ -195,3 +195,22 @@ acpi_numa_init()acpi_numa_arch_fixup ();return 0 ; } + +int +acpi_get_pxm (acpi_handle h) +{ +unsigned long pxm =-1 ; +acpi_status status; +acpi_handle handle ; +acpi_handle phandle = h; + +do { + handle = phandle; + status =acpi_evaluate_integer (handle,"_PXM" ,NULL , &pxm); +if (ACPI_SUCCESS (status)) +return (int )pxm; + status =acpi_get_parent (handle, &phandle); + }while (ACPI_SUCCESS (status)); +return -1 ; +} +EXPORT_SYMBOL (acpi_get_pxm);
include/linux/acpi.h renamed from include/linux/acpi.h~acpi_pxm_support +8 -0
@@ -477,4 +477,12 @@ static inline int acpi_blacklisted(void)#endif /*!CONFIG_ACPI_INTERPRETER*/ +#ifdef CONFIG_ACPI_NUMA +int acpi_get_pxm (acpi_handle handle); +#else +static inline int acpi_get_pxm (acpi_handle handle) +{ +return 0 ; +} +#endif #endif /*_LINUX_ACPI_H*/
_
Re: [ACPI] PATCH-ACPI based CPU hotplug[3/6]-Mapping lsapic to cpu
Quoted 13 lines · Keiichiro Tokunaga
Quoted 12 lines · Alex Williamson
Quoted 7 lines · Keiichiro Tokunaga
I would like to suggest introducing a new function '
acpi_get_pxm()' since other drivers might need it in the future. Acutally, ACPI container hotplug will be using it soon.Here is a patch creating the function.
Nice, I have a couple I/O locality patches that could be simplified
with this function.
Quoted 7 lines
Quoted 5 lines
include/linux/acpi.h static inline int acpi_blacklisted(void)
Quoted 4 lines
include/linux/acpi.h renamed from include/linux/acpi.h~acpi_pxm_support +4
-0+#ifdef CONFIG_ACPI_NUMA +int acpi_get_pxm (acpi_handle handle); +#else +static inline int acpi_get_pxm (acpi_handle hanle)Trivial typo here ---> ^^^^^ handle
Oh, good catch:)
Merged your changes, thanks again.
-Anil
Re: [ACPI] PATCH-ACPI based CPU hotplug[3/6]-Mapping lsapic to cpu
In reply to Keiichiro TokunagaQuoted 11 lines · Keiichiro Tokunaga
Quoted 10 lines · Alex Williamson
Quoted 7 lines · Keiichiro Tokunaga
I would like to suggest introducing a new function '
acpi_get_pxm()' since other drivers might need it in the future. Acutally, ACPI container hotplug will be using it soon.Here is a patch creating the function.
Nice, I have a couple I/O locality patches that could be simplified
Here is the revised patch which now fixes the all issues that were discussed.
- Now defines and uses acpi_get_pxm
- small bugfix "change __initdata to __devinitdata for pxm_to_nid_map varable
---
Name:acpi_hotplug_arch.patch
Status: Tested on 2.6.9-rc2
Depends:
Version: applies on 2.6.9-rc2
Description:
This patch provides the architecture specifice support for mapping lsapic to cpu array. Currently this supports just IA64. Support for IA32 and x86_64 is in progress
changes from previous release:
- Now defines and uses acpi_get_pxm
- small bugfix "change __initdata to __devinitdata for pxm_to_nid_map varable
---
linux-2.6.9-rc2-askeshav/arch/i386/kernel/acpi/boot.c | 22 +++ linux-2.6.9-rc2-askeshav/arch/ia64/kernel/acpi.c | 107 +++++++++++++++++- linux-2.6.9-rc2-askeshav/drivers/acpi/numa.c | 19 +++ linux-2.6.9-rc2-askeshav/include/linux/acpi.h | 14 ++ 4 files changed, 159 insertions(+), 3 deletions(-)
include/linux/acpi.h renamed from include/linux/acpi.h~acpi_hotplug_arch +14 -0
@@ -396,6 +396,12 @@ void acpi_numa_processor_affinity_init (void acpi_numa_memory_affinity_init (struct acpi_table_memory_affinity *ma);void acpi_numa_arch_fixup (void ); +#ifdef CONFIG_ACPI_HOTPLUG_CPU +/* Arch dependent functions for cpu hotplug support */ +int acpi_map_lsapic (acpi_handle handle,int *pcpu); +int acpi_unmap_lsapic (int cpu); +#endif /* CONFIG_ACPI_HOTPLUG_CPU */ +extern int acpi_mp_config;extern u32 pci_mmcfg_base_addr;
@@ -471,4 +477,12 @@ static inline int acpi_blacklisted(void)#endif /*!CONFIG_ACPI_INTERPRETER*/ +#ifdef CONFIG_ACPI_NUMA +int acpi_get_pxm (acpi_handle handle); +#else +static inline int acpi_get_pxm (acpi_handle handle) +{ +return 0 ; +} +#endif #endif /*_LINUX_ACPI_H*/
arch/ia64/kernel/acpi.c renamed from arch/ia64/kernel/acpi.c~acpi_hotplug_arch +105 -2
120 lines not on this page · raw message
arch/i386/kernel/acpi/boot.c renamed from arch/i386/kernel/acpi/boot.c~acpi_hotplug_arch +22 -0
@@ -478,6 +478,28 @@ unsigned int acpi_register_gsi(u32 gsi, }EXPORT_SYMBOL (acpi_register_gsi); +/* +* ACPI based hotplug support for CPU +*/ +#ifdef CONFIG_ACPI_HOTPLUG_CPU +int +acpi_map_lsapic (acpi_handle handle,int *pcpu) +{ +/* TBD */ +return -EINVAL ; +} +EXPORT_SYMBOL (acpi_map_lsapic); + + +int +acpi_unmap_lsapic (int cpu) +{ +/* TBD */ +return -EINVAL ; +} +EXPORT_SYMBOL (acpi_unmap_lsapic); +#endif /* CONFIG_ACPI_HOTPLUG_CPU */ + static unsigned long __init acpi_scan_rsdp ( unsigned long start,
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_hotplug_arch +18 -1
@@ -22,7 +22,7 @@* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * */ - +#include <linux/module.h> #include <linux/config.h> #include <linux/init.h> #include <linux/kernel.h>
@@ -195,3 +195,20 @@ acpi_numa_init()acpi_numa_arch_fixup ();return 0 ; } + +int +acpi_get_pxm (acpi_handle handle) +{ +unsigned long pxm; +acpi_status status; +acpi_handle phandle; + +do { + status =acpi_evaluate_integer (handle,"_PXM" ,NULL , &pxm); +if (ACPI_SUCCESS (status)) +return (int )pxm; + status =acpi_get_parent (handle, &phandle); + }while (ACPI_SUCCESS (status)); +return -1 ; +} +EXPORT_SYMBOL (acpi_get_pxm);
_
Re: [ACPI] PATCH-ACPI based CPU hotplug[3/6]-Mapping lsapic to cpu
Quoted 8 lines · On Fri, 24 Sep 2004 16:36:32 -0700 Keshavamurthy Anil S wrote:
Quoted 7 lines · Keiichiro Tokunaga
Quoted 6 lines · Alex Williamson
Quoted 5 lines · Keiichiro Tokunaga
I would like to suggest introducing a new function '
acpi_get_pxm()' since other drivers might need it in the future. Acutally, ACPI container hotplug will be using it soon.
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
Here is a patch creating the function.
Nice, I have a couple I/O locality patches that could be simplified
Here is the revised patch which now fixes the all issues that were discussed.
- Now defines and usesacpi_get_pxm
- small bugfix "change__initdatato__devinitdataforpxm_to_nid_mapvarable
Thanks for your work! But, you might forget to merge the small bugfix patch. See the diffstat below. The target file of small bugfix is include/asm-ia64/acpi.h, but it didn't show up below:)
Quoted 5 lines
linux-2.6.9-rc2-askeshav/arch/i386/kernel/acpi/boot.c | 22 +++ linux-2.6.9-rc2-askeshav/arch/ia64/kernel/acpi.c | 107 +++++++++++++++++- linux-2.6.9-rc2-askeshav/drivers/acpi/numa.c | 19 +++ linux-2.6.9-rc2-askeshav/include/linux/acpi.h | 14 ++ 4 files changed, 159 insertions(+), 3 deletions(-)
Thanks,
Keiichiro Tokunaga
Re: [ACPI] PATCH-ACPI based CPU hotplug[3/6]-Mapping lsapic to cpu
In reply to Keshavamurthy Anil SQuoted 8 lines · On Fri, 24 Sep 2004 16:36:32 -0700 Keshavamurthy Anil S wrote:
Quoted 7 lines · Keiichiro Tokunaga
Quoted 6 lines · Alex Williamson
Quoted 5 lines · Keiichiro Tokunaga
I would like to suggest introducing a new function '
acpi_get_pxm()' since other drivers might need it in the future. Acutally, ACPI container hotplug will be using it soon.
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
Here is a patch creating the function.
Nice, I have a couple I/O locality patches that could be simplified
Here is the revised patch which now fixes the all issues that were discussed.
- Now defines and usesacpi_get_pxm
- small bugfix "change__initdatato__devinitdataforpxm_to_nid_mapvarable
One more thing. Did you modify my acpi_get_pxm.patch by hand? That causes an infinite loop. Please apply my fix patch.
Quoted 16 lines
(quoted diff) +16
-0+int +acpi_get_pxm(acpi_handle handle) +{ + unsigned long pxm; + acpi_status status; + acpi_handle phandle; + + do { + status = acpi_evaluate_integer(handle, "_PXM", NULL, &pxm); + if (ACPI_SUCCESS(status)) + return (int)pxm; + status = acpi_get_parent(handle, &phandle); + } while(ACPI_SUCCESS(status)); + return -1; +} +EXPORT_SYMBOL(acpi_get_pxm);
Quoted 1 line
_
This do-loop never ends...
Thanks,
Keiichiro Tokunaga
Status: Tested on 2.6.9-rc2
---
linux-2.6.9-rc2-092704-kei/drivers/acpi/numa.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-)
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_get_pxm-fix +4 -2
@@ -198,13 +198,15 @@ acpi_numa_init() }int -acpi_get_pxm (acpi_handle handle) +acpi_get_pxm (acpi_handle h) {unsigned long pxm;acpi_status status; -acpi_handle phandle; +acpi_handle handle; +acpi_handle phandle = h; do { + handle = phandle; status = acpi_evaluate_integer(handle, "_PXM", NULL, &pxm); if (ACPI_SUCCESS(status)) return (int)pxm;
_
Re: [ACPI] PATCH-ACPI based CPU hotplug[3/6]-Mapping lsapic to cpu
Quoted 2 lines · Keiichiro Tokunaga
One more thing. Did you modify my acpi_get_pxm.patch by hand? That causes an infinite loop. Please apply my fix patch.
OOPS!! Now applying cleanly. Refreshing my patch again. Thanks.
Hi Len,
I hope all of my ACPI based CPU hotplug patches[1-6] have been reviewed
extensively and I have fixed all the issues that were raised. Do you think it is reasonable now to have it in your test tree? Please let me know.
Once this goes to your test tree, I will work with the community to provide ACPI based NUMA NODE hotplug support patches.
thanks,
Anil
---
Name:acpi_hotplug_arch.patch
Status: Tested on 2.6.9-rc2
Depends:
Version: applies on 2.6.9-rc2
Description:
This patch provides the architecture specifice support for mapping lsapic to cpu array. Currently this supports just IA64. Support for IA32 and x86_64 is in progress
---
linux-2.6.9-rc2-askeshav/arch/i386/kernel/acpi/boot.c | 22 +++ linux-2.6.9-rc2-askeshav/arch/ia64/kernel/acpi.c | 107 +++++++++++++++++- linux-2.6.9-rc2-askeshav/drivers/acpi/numa.c | 21 +++ linux-2.6.9-rc2-askeshav/include/asm-ia64/acpi.h | 2 linux-2.6.9-rc2-askeshav/include/linux/acpi.h | 14 ++ 5 files changed, 162 insertions(+), 4 deletions(-)
include/linux/acpi.h renamed from include/linux/acpi.h~acpi_hotplug_arch +14 -0
@@ -396,6 +396,12 @@ void acpi_numa_processor_affinity_init (void acpi_numa_memory_affinity_init (struct acpi_table_memory_affinity *ma);void acpi_numa_arch_fixup (void ); +#ifdef CONFIG_ACPI_HOTPLUG_CPU +/* Arch dependent functions for cpu hotplug support */ +int acpi_map_lsapic (acpi_handle handle,int *pcpu); +int acpi_unmap_lsapic (int cpu); +#endif /* CONFIG_ACPI_HOTPLUG_CPU */ +extern int acpi_mp_config;extern u32 pci_mmcfg_base_addr;
@@ -471,4 +477,12 @@ static inline int acpi_blacklisted(void)#endif /*!CONFIG_ACPI_INTERPRETER*/ +#ifdef CONFIG_ACPI_NUMA +int acpi_get_pxm (acpi_handle handle); +#else +static inline int acpi_get_pxm (acpi_handle handle) +{ +return 0 ; +} +#endif #endif /*_LINUX_ACPI_H*/
arch/ia64/kernel/acpi.c renamed from arch/ia64/kernel/acpi.c~acpi_hotplug_arch +105 -2
120 lines not on this page · raw message
arch/i386/kernel/acpi/boot.c renamed from arch/i386/kernel/acpi/boot.c~acpi_hotplug_arch +22 -0
@@ -478,6 +478,28 @@ unsigned int acpi_register_gsi(u32 gsi, }EXPORT_SYMBOL (acpi_register_gsi); +/* +* ACPI based hotplug support for CPU +*/ +#ifdef CONFIG_ACPI_HOTPLUG_CPU +int +acpi_map_lsapic (acpi_handle handle,int *pcpu) +{ +/* TBD */ +return -EINVAL ; +} +EXPORT_SYMBOL (acpi_map_lsapic); + + +int +acpi_unmap_lsapic (int cpu) +{ +/* TBD */ +return -EINVAL ; +} +EXPORT_SYMBOL (acpi_unmap_lsapic); +#endif /* CONFIG_ACPI_HOTPLUG_CPU */ + static unsigned long __init acpi_scan_rsdp ( unsigned long start,
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_hotplug_arch +20 -1
@@ -22,7 +22,7 @@* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * */ - +#include <linux/module.h> #include <linux/config.h> #include <linux/init.h> #include <linux/kernel.h>
@@ -195,3 +195,22 @@ acpi_numa_init()acpi_numa_arch_fixup ();return 0 ; } + +int +acpi_get_pxm (acpi_handle h) +{ +unsigned long pxm; +acpi_status status; +acpi_handle handle; +acpi_handle phandle = h; + +do { + handle = phandle; + status =acpi_evaluate_integer (handle,"_PXM" ,NULL , &pxm); +if (ACPI_SUCCESS (status)) +return (int )pxm; + status =acpi_get_parent (handle, &phandle); + }while (ACPI_SUCCESS (status)); +return -1 ; +} +EXPORT_SYMBOL (acpi_get_pxm);
include/asm-ia64/acpi.h renamed from include/asm-ia64/acpi.h~acpi_hotplug_arch +1 -1
@@ -101,7 +101,7 @@ int acpi_gsi_to_irq (u32 gsi, unsigned i#ifdef CONFIG_ACPI_NUMA /* Proximity bitmap length; _PXM is at most 255 (8 bit)*/ #define MAX_PXM_DOMAINS (256) -extern int __initdata pxm_to_nid_map[MAX_PXM_DOMAINS ]; +extern int __devinitdata pxm_to_nid_map[MAX_PXM_DOMAINS ];extern int __initdata nid_to_pxm_map[MAX_NUMNODES ];#endif
_
PATCH-ACPI based CPU hotplug[4/6]-Dynamic cpu register/unregister support
In reply to Keshavamurthy Anil S---
Name:topology.patch
Status:Tested on 2.6.9-rc2
Depends:
Version: applies on 2.6.9-rc2
Description:
Extends support for dynamic registration and unregistration of the cpu, by implementing and exporting arch_register_cpu()/arch_unregister_cpu(). Also combines multiple implementation of topology_init() functions to single topology_init() in case of ia64 architecture.
---
/dev/null | 43 ------ linux-2.6.9-rc2-askeshav/arch/i386/mach-default/topology.c | 31 ++++ linux-2.6.9-rc2-askeshav/arch/ia64/dig/Makefile | 5 linux-2.6.9-rc2-askeshav/arch/ia64/kernel/Makefile | 3 linux-2.6.9-rc2-askeshav/arch/ia64/kernel/topology.c | 91 +++++++++++++ linux-2.6.9-rc2-askeshav/arch/ia64/mm/numa.c | 35 ----- linux-2.6.9-rc2-askeshav/drivers/base/cpu.c | 20 ++ linux-2.6.9-rc2-askeshav/include/asm-i386/cpu.h | 17 -- linux-2.6.9-rc2-askeshav/include/asm-ia64/cpu.h | 5 linux-2.6.9-rc2-askeshav/include/linux/cpu.h | 3 10 files changed, 154 insertions(+), 99 deletions(-)
arch/ia64/dig/topology.c deleted +0 -43
@@ -1,43 +0,0 @@ -/* -* arch/ia64/dig/topology.c -* Popuate driverfs with topology information. -* Derived entirely from i386/mach-default.c -* Intel Corporation - Ashok Raj -*/ -#include <linux/init.h> -#include <linux/smp.h> -#include <linux/cpumask.h> -#include <linux/percpu.h> -#include <linux/notifier.h> -#include <linux/cpu.h> -#include <asm/cpu.h> - -static DEFINE_PER_CPU(struct ia64_cpu, cpu_devices); - -/* -* First Pass: simply borrowed code for now. Later should hook into -* hotplug notification for node/cpu/memory as applicable -*/ - -static int arch_register_cpu (int num) -{ -struct node *parent =NULL ; - -#ifdef CONFIG_NUMA -//parent = &node_devices[cpu_to_node(num)].node; -#endif - -return register_cpu (&per_cpu (cpu_devices,num).cpu, num, parent); -} - -static int __init topology_init (void ) -{ -int i; - -for_each_cpu (i) { -arch_register_cpu (i); - } -return 0 ; -} - -subsys_initcall (topology_init);
arch/ia64/dig/Makefile renamed from arch/ia64/dig/Makefile~topology +0 -5
@@ -6,9 +6,4 @@ # obj-y := setup.o - -ifndef CONFIG_NUMA -obj-$(CONFIG_IA64_DIG) += topology.o -endif - obj-$(CONFIG_IA64_GENERIC) += machvec.o
arch/ia64/mm/numa.c renamed from arch/ia64/mm/numa.c~topology +0 -35
@@ -20,8 +20,6 @@#include <asm/mmzone.h> #include <asm/numa.h> -static struct node *sysfs_nodes; -static struct cpu *sysfs_cpus;/* * The following structures are usually initialized by ACPI or
@@ -50,36 +48,3 @@ paddr_to_nid(unsigned long paddr)return (i < num_node_memblks) ? node_memblk[i].nid : (num_node_memblks ?-1 :0 ); } -static int __init topology_init (void ) -{ -int i, err =0 ; - - sysfs_nodes =kmalloc (sizeof (struct node ) * numnodes,GFP_KERNEL ); -if (!sysfs_nodes) { - err = -ENOMEM ; - goto out; - } -memset (sysfs_nodes,0 ,sizeof (struct node ) * numnodes); - - sysfs_cpus =kmalloc (sizeof (struct cpu ) *NR_CPUS ,GFP_KERNEL ); -if (!sysfs_cpus) { -kfree (sysfs_nodes); - err = -ENOMEM ; - goto out; - } -memset (sysfs_cpus,0 ,sizeof (struct cpu ) *NR_CPUS ); - -for (i =0 ; i < numnodes; i++) -if ((err =register_node (&sysfs_nodes[i], i,0 ))) - goto out; - -for (i =0 ; i <NR_CPUS ; i++) -if (cpu_online (i)) -if ((err =register_cpu (&sysfs_cpus[i], i, - &sysfs_nodes[cpu_to_node (i)]))) - goto out; - out: -return err; -} - -__initcall (topology_init);
include/linux/cpu.h renamed from include/linux/cpu.h~topology +3 -0
@@ -32,6 +32,9 @@ struct cpu { };extern int register_cpu (struct cpu *,int ,struct node *); +#ifdef CONFIG_HOTPLUG_CPU +extern void unregister_cpu (struct cpu *,struct node *); +#endif struct notifier_block ;#ifdef CONFIG_SMP
include/asm-ia64/cpu.h renamed from include/asm-ia64/cpu.h~topology +5 -0
@@ -14,4 +14,9 @@ DECLARE_PER_CPU(struct ia64_cpu, cpu_devDECLARE_PER_CPU (int, cpu_state); +extern int arch_register_cpu (int num); +#ifdef CONFIG_HOTPLUG_CPU +extern void arch_unregister_cpu (int ); +#endif +#endif /* _ASM_IA64_CPU_H_ */
arch/ia64/kernel/topology.c new file +91 -0
91 lines not on this page · raw message
arch/ia64/kernel/Makefile renamed from arch/ia64/kernel/Makefile~topology +2 -1
@@ -6,7 +6,8 @@ extra-y := head.o init_task.o vmlinux.ld obj-y := acpi.o entry.o efi.o efi_stub.o gate-data.o fsys.o ia64_ksyms.o irq.o irq_ia64.o \ irq_lsapic.o ivt.o machvec.o pal.o patch.o process.o perfmon.o ptrace.o sal.o \ - salinfo.o semaphore.o setup.o signal.o sys_ia64.o time.o traps.o unaligned.o unwind.o mca.o mca_asm.o + salinfo.o semaphore.o setup.o signal.o sys_ia64.o time.o traps.o unaligned.o \ + unwind.o mca.o mca_asm.o topology.o obj-$(CONFIG_IA64_BRL_EMU) += brl_emu.o obj-$(CONFIG_IA64_GENERIC) += acpi-ext.o
include/asm-i386/cpu.h renamed from include/asm-i386/cpu.h~topology +4 -13
@@ -11,18 +11,9 @@ struct i386_cpu { struct cpu cpu; };extern struct i386_cpu cpu_devices[NR_CPUS ]; - - -static inline int arch_register_cpu (int num){ -struct node *parent =NULL ; - -#ifdef CONFIG_NUMA -int node =cpu_to_node (num); -if (node_online (node)) - parent = &node_devices[node].node; -#endif /* CONFIG_NUMA */ - -return register_cpu (&cpu_devices[num].cpu, num, parent); -} +extern int arch_register_cpu (int num); +#ifdef CONFIG_HOTPLUG_CPU +extern void arch_unregister_cpu (int ); +#endif #endif /* _ASM_I386_CPU_H_ */
arch/i386/mach-default/topology.c renamed from arch/i386/mach-default/topology.c~topology +31 -0
@@ -31,6 +31,37 @@struct i386_cpu cpu_devices[NR_CPUS ]; +int arch_register_cpu (int num){ +struct node *parent =NULL ; + +#ifdef CONFIG_NUMA +int node =cpu_to_node (num); +if (node_online (node)) + parent = &node_devices[node].node; +#endif /* CONFIG_NUMA */ + +return register_cpu (&cpu_devices[num].cpu, num, parent); +} + +#ifdef CONFIG_HOTPLUG_CPU + +void arch_unregister_cpu (int num) { +struct node *parent =NULL ; + +#ifdef CONFIG_NUMA +int node =cpu_to_node (num); +if (node_online (node)) + parent = &node_devices[node].node; +#endif /* CONFIG_NUMA */ + +return unregister_cpu (&cpu_devices[num].cpu, parent); +} +EXPORT_SYMBOL (arch_register_cpu); +EXPORT_SYMBOL (arch_unregister_cpu); +#endif /*CONFIG_HOTPLUG_CPU*/ + + +#ifdef CONFIG_NUMA #include <linux/mmzone.h> #include <asm/node.h>
drivers/base/cpu.c renamed from drivers/base/cpu.c~topology +18 -2
@@ -46,10 +46,23 @@ static ssize_t store_online(struct sys_d } static SYSDEV_ATTR(online, 0600, show_online, store_online); -static void __init register_cpu_control (struct cpu *cpu) +static void __devinit register_cpu_control (struct cpu *cpu) {sysdev_create_file (&cpu->sysdev, &attr_online); } +void unregister_cpu (struct cpu *cpu,struct node *root) +{ + +if (root) +sysfs_remove_link (&root->sysdev.kobj, +kobject_name (&cpu->sysdev.kobj)); +sysdev_remove_file (&cpu->sysdev, &attr_online); + +sysdev_unregister (&cpu->sysdev); + +return ; +} +EXPORT_SYMBOL (unregister_cpu);#else /* ... !CONFIG_HOTPLUG_CPU */ static inline void register_cpu_control (struct cpu *cpu) {
@@ -64,7 +77,7 @@ static inline void register_cpu_control(* * Initialize and register the CPU device. */ -int __init register_cpu (struct cpu *cpu,int num,struct node *root) +int __devinit register_cpu (struct cpu *cpu,int num,struct node *root) {int error;
@@ -81,6 +94,9 @@ int __init register_cpu(struct cpu *cpu,register_cpu_control (cpu);return error; } +#ifdef CONFIG_HOTPLUG_CPU +EXPORT_SYMBOL (register_cpu); +#endif
_
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
Re: [ACPI] PATCH-ACPI based CPU hotplug[4/6]-Dynamic cpu register/unregister support
Quoted 15 lines · On Mon, 20 Sep 2004 09:41:07 -0700 Keshavamurthy Anil S wrote:
---
Name:topology.patch
Status:Tested on 2.6.9-rc2Signed-off-by Anil S Keshavamurthy <[email protected]>Depends:
Version: applies on 2.6.9-rc2
Description:
Extends support for dynamic registration and unregistration of the cpu, by implementing and exporting arch_register_cpu()/arch_unregister_cpu(). Also combines multiple implementation oftopology_init()functions to singletopology_init()in case of ia64 architecture.
---(quoted diff) +2
-0+void arch_unregister_cpu(int num) +{
Review
Quoted 10 lines
(quoted diff) +10
-0+ struct node *parent = NULL; + +#ifdef CONFIG_NUMA + int node = cpu_to_node(num); + if (node_online(node)) + parent = &sysfs_nodes[node]; +#endif /* CONFIG_NUMA */ + + return unregister_cpu(&sysfs_cpus[num].cpu, parent); +}
I don't think that the check 'if (node_online(node))' is necessary because sysfs_nodes[node] is there no matter if the node is online or offline. sysfs_nodes[] is cleared only when unregister_node() is called and it would be always called after unregister_cpu().
Thanks,
Keiichiro Tokunaga
Name: arch_register_cpu_fix.patch
Status: Tested on 2.6.9-rc2
---
linux-2.6.9-rc2-fix-kei/arch/ia64/kernel/topology.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-)
arch/ia64/kernel/topology.c renamed from arch/ia64/kernel/topology.c~arch_register_cpu_fix +1 -2
@@ -46,8 +46,7 @@ void arch_unregister_cpu(int num)#ifdef CONFIG_NUMA int node =cpu_to_node (num); -if (node_online (node)) - parent = &sysfs_nodes[node]; + parent = &sysfs_nodes[node];#endif /* CONFIG_NUMA */ return unregister_cpu (&sysfs_cpus[num].cpu, parent);
_
Re: [ACPI] PATCH-ACPI based CPU hotplug[4/6]-Dynamic cpu register/unregister support
Quoted 23 lines · Keiichiro Tokunaga
Quoted 22 lines · On Mon, 20 Sep 2004 09:41:07 -0700 Keshavamurthy Anil S wrote:
---
Name:topology.patch
Status:Tested on 2.6.9-rc2Signed-off-by Anil S Keshavamurthy <[email protected]>Depends:
Version: applies on 2.6.9-rc2
Description:
Extends support for dynamic registration and unregistration of the cpu, by implementing and exporting arch_register_cpu()/arch_unregister_cpu(). Also combines multiple implementation oftopology_init()functions to singletopology_init()in case of ia64 architecture.
---(quoted diff) +9
-0+void arch_unregister_cpu(int num) +{ + struct node *parent = NULL; + +#ifdef CONFIG_NUMA + int node = cpu_to_node(num); + if (node_online(node)) + parent = &sysfs_nodes[node]; +#endif /* CONFIG_NUMA */
Quoted 8 lines
Review
Quoted 3 lines
(quoted diff) +3
-0+ + return unregister_cpu(&sysfs_cpus[num].cpu, parent); +}I don't think that the check 'if (
node_online(node))' is necessary because sysfs_nodes[node] is there no matter if the node is online or offline. sysfs_nodes[] is cleared only whenunregister_node()is called and it would be always called afterunregister_cpu().
Yes, I agree with you. I will remove the check, or simply apply your patch:) thanks,
Anil
Re: [ACPI] PATCH-ACPI based CPU hotplug[4/6]-Dynamic cpu register/unregister support
In reply to Keiichiro TokunagaQuoted 5 lines · Keiichiro Tokunaga
On Mon, 20 Sep 2004 09:41:07 -0700 Keshavamurthy Anil S wrote:
I don't think that the check 'if (node_online(node))' is necessary because sysfs_nodes[node] is there no matter if the node is online or offline. sysfs_nodes[] is cleared only whenunregister_node()is called and it would be always called afterunregister_cpu().
Refreshed this patch to address the above issues. Please let me know if you see any other issue with this patch.
---
Name:topology.patch
Status:Tested on 2.6.9-rc2
Depends:
Version: applies on 2.6.9-rc2
Description:
Extends support for dynamic registration and unregistration of the cpu, by implementing and exporting arch_register_cpu()/arch_unregister_cpu(). Also combines multiple implementation of topology_init() functions to single topology_init() in case of ia64 architecture.
---
/dev/null | 43 ------ linux-2.6.9-rc2-askeshav/arch/i386/mach-default/topology.c | 31 ++++ linux-2.6.9-rc2-askeshav/arch/ia64/dig/Makefile | 5 linux-2.6.9-rc2-askeshav/arch/ia64/kernel/Makefile | 3 linux-2.6.9-rc2-askeshav/arch/ia64/kernel/topology.c | 90 +++++++++++++ linux-2.6.9-rc2-askeshav/arch/ia64/mm/numa.c | 35 ----- linux-2.6.9-rc2-askeshav/drivers/base/cpu.c | 20 ++ linux-2.6.9-rc2-askeshav/include/asm-i386/cpu.h | 17 -- linux-2.6.9-rc2-askeshav/include/asm-ia64/cpu.h | 5 linux-2.6.9-rc2-askeshav/include/linux/cpu.h | 3 10 files changed, 153 insertions(+), 99 deletions(-)
arch/ia64/dig/topology.c deleted +0 -43
@@ -1,43 +0,0 @@ -/* -* arch/ia64/dig/topology.c -* Popuate driverfs with topology information. -* Derived entirely from i386/mach-default.c -* Intel Corporation - Ashok Raj -*/ -#include <linux/init.h> -#include <linux/smp.h> -#include <linux/cpumask.h> -#include <linux/percpu.h> -#include <linux/notifier.h> -#include <linux/cpu.h> -#include <asm/cpu.h> - -static DEFINE_PER_CPU(struct ia64_cpu, cpu_devices); - -/* -* First Pass: simply borrowed code for now. Later should hook into -* hotplug notification for node/cpu/memory as applicable -*/ - -static int arch_register_cpu (int num) -{ -struct node *parent =NULL ; - -#ifdef CONFIG_NUMA -//parent = &node_devices[cpu_to_node(num)].node; -#endif - -return register_cpu (&per_cpu (cpu_devices,num).cpu, num, parent); -} - -static int __init topology_init (void ) -{ -int i; - -for_each_cpu (i) { -arch_register_cpu (i); - } -return 0 ; -} - -subsys_initcall (topology_init);
arch/ia64/dig/Makefile renamed from arch/ia64/dig/Makefile~topology +0 -5
@@ -6,9 +6,4 @@ # obj-y := setup.o - -ifndef CONFIG_NUMA -obj-$(CONFIG_IA64_DIG) += topology.o -endif - obj-$(CONFIG_IA64_GENERIC) += machvec.o
arch/ia64/mm/numa.c renamed from arch/ia64/mm/numa.c~topology +0 -35
@@ -20,8 +20,6 @@#include <asm/mmzone.h> #include <asm/numa.h> -static struct node *sysfs_nodes; -static struct cpu *sysfs_cpus;/* * The following structures are usually initialized by ACPI or
@@ -50,36 +48,3 @@ paddr_to_nid(unsigned long paddr)return (i < num_node_memblks) ? node_memblk[i].nid : (num_node_memblks ?-1 :0 ); } -static int __init topology_init (void ) -{ -int i, err =0 ; - - sysfs_nodes =kmalloc (sizeof (struct node ) * numnodes,GFP_KERNEL ); -if (!sysfs_nodes) { - err = -ENOMEM ; - goto out; - } -memset (sysfs_nodes,0 ,sizeof (struct node ) * numnodes); - - sysfs_cpus =kmalloc (sizeof (struct cpu ) *NR_CPUS ,GFP_KERNEL ); -if (!sysfs_cpus) { -kfree (sysfs_nodes); - err = -ENOMEM ; - goto out; - } -memset (sysfs_cpus,0 ,sizeof (struct cpu ) *NR_CPUS ); - -for (i =0 ; i < numnodes; i++) -if ((err =register_node (&sysfs_nodes[i], i,0 ))) - goto out; - -for (i =0 ; i <NR_CPUS ; i++) -if (cpu_online (i)) -if ((err =register_cpu (&sysfs_cpus[i], i, - &sysfs_nodes[cpu_to_node (i)]))) - goto out; - out: -return err; -} - -__initcall (topology_init);
include/linux/cpu.h renamed from include/linux/cpu.h~topology +3 -0
@@ -32,6 +32,9 @@ struct cpu { };extern int register_cpu (struct cpu *,int ,struct node *); +#ifdef CONFIG_HOTPLUG_CPU +extern void unregister_cpu (struct cpu *,struct node *); +#endif struct notifier_block ;#ifdef CONFIG_SMP
include/asm-ia64/cpu.h renamed from include/asm-ia64/cpu.h~topology +5 -0
@@ -14,4 +14,9 @@ DECLARE_PER_CPU(struct ia64_cpu, cpu_devDECLARE_PER_CPU (int, cpu_state); +extern int arch_register_cpu (int num); +#ifdef CONFIG_HOTPLUG_CPU +extern void arch_unregister_cpu (int ); +#endif +#endif /* _ASM_IA64_CPU_H_ */
arch/ia64/kernel/topology.c new file +90 -0
90 lines not on this page · raw message
arch/ia64/kernel/Makefile renamed from arch/ia64/kernel/Makefile~topology +2 -1
@@ -6,7 +6,8 @@ extra-y := head.o init_task.o vmlinux.ld obj-y := acpi.o entry.o efi.o efi_stub.o gate-data.o fsys.o ia64_ksyms.o irq.o irq_ia64.o \ irq_lsapic.o ivt.o machvec.o pal.o patch.o process.o perfmon.o ptrace.o sal.o \ - salinfo.o semaphore.o setup.o signal.o sys_ia64.o time.o traps.o unaligned.o unwind.o mca.o mca_asm.o + salinfo.o semaphore.o setup.o signal.o sys_ia64.o time.o traps.o unaligned.o \ + unwind.o mca.o mca_asm.o topology.o obj-$(CONFIG_IA64_BRL_EMU) += brl_emu.o obj-$(CONFIG_IA64_GENERIC) += acpi-ext.o
include/asm-i386/cpu.h renamed from include/asm-i386/cpu.h~topology +4 -13
@@ -11,18 +11,9 @@ struct i386_cpu { struct cpu cpu; };extern struct i386_cpu cpu_devices[NR_CPUS ]; - - -static inline int arch_register_cpu (int num){ -struct node *parent =NULL ; - -#ifdef CONFIG_NUMA -int node =cpu_to_node (num); -if (node_online (node)) - parent = &node_devices[node].node; -#endif /* CONFIG_NUMA */ - -return register_cpu (&cpu_devices[num].cpu, num, parent); -} +extern int arch_register_cpu (int num); +#ifdef CONFIG_HOTPLUG_CPU +extern void arch_unregister_cpu (int ); +#endif #endif /* _ASM_I386_CPU_H_ */
arch/i386/mach-default/topology.c renamed from arch/i386/mach-default/topology.c~topology +31 -0
@@ -31,6 +31,37 @@struct i386_cpu cpu_devices[NR_CPUS ]; +int arch_register_cpu (int num){ +struct node *parent =NULL ; + +#ifdef CONFIG_NUMA +int node =cpu_to_node (num); +if (node_online (node)) + parent = &node_devices[node].node; +#endif /* CONFIG_NUMA */ + +return register_cpu (&cpu_devices[num].cpu, num, parent); +} + +#ifdef CONFIG_HOTPLUG_CPU + +void arch_unregister_cpu (int num) { +struct node *parent =NULL ; + +#ifdef CONFIG_NUMA +int node =cpu_to_node (num); +if (node_online (node)) + parent = &node_devices[node].node; +#endif /* CONFIG_NUMA */ + +return unregister_cpu (&cpu_devices[num].cpu, parent); +} +EXPORT_SYMBOL (arch_register_cpu); +EXPORT_SYMBOL (arch_unregister_cpu); +#endif /*CONFIG_HOTPLUG_CPU*/ + + +#ifdef CONFIG_NUMA #include <linux/mmzone.h> #include <asm/node.h>
drivers/base/cpu.c renamed from drivers/base/cpu.c~topology +18 -2
@@ -46,10 +46,23 @@ static ssize_t store_online(struct sys_d } static SYSDEV_ATTR(online, 0600, show_online, store_online); -static void __init register_cpu_control (struct cpu *cpu) +static void __devinit register_cpu_control (struct cpu *cpu) {sysdev_create_file (&cpu->sysdev, &attr_online); } +void unregister_cpu (struct cpu *cpu,struct node *root) +{ + +if (root) +sysfs_remove_link (&root->sysdev.kobj, +kobject_name (&cpu->sysdev.kobj)); +sysdev_remove_file (&cpu->sysdev, &attr_online); + +sysdev_unregister (&cpu->sysdev); + +return ; +} +EXPORT_SYMBOL (unregister_cpu);#else /* ... !CONFIG_HOTPLUG_CPU */ static inline void register_cpu_control (struct cpu *cpu) {
@@ -64,7 +77,7 @@ static inline void register_cpu_control(* * Initialize and register the CPU device. */ -int __init register_cpu (struct cpu *cpu,int num,struct node *root) +int __devinit register_cpu (struct cpu *cpu,int num,struct node *root) {int error;
@@ -81,6 +94,9 @@ int __init register_cpu(struct cpu *cpu,register_cpu_control (cpu);return error; } +#ifdef CONFIG_HOTPLUG_CPU +EXPORT_SYMBOL (register_cpu); +#endif
_
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
PATCH-ACPI based CPU hotplug[5/6]-ACPI processor driver extension
In reply to Keshavamurthy Anil SChanges form previous version
1) Added depends on EXPERIMENTAL in kconfig file
---
Name:processor_drv.patch
Status:Tested on 2.6.9-rc2
Depends:
Version: applies on 2.6.9-rc2
Description:
Extends the processor driver to support ACPI based Physical CPU hotplug.
---
drivers/acpi/Kconfig renamed from drivers/acpi/Kconfig~processor_drv +8 -0
@@ -129,6 +129,14 @@ config ACPI_PROCESSOR ACPI C2 and C3 processor states to save power, on systems that support it. +config ACPI_HOTPLUG_CPU + bool "Processor Hotplug (EXPERIMENTAL)" + depends on ACPI_PROCESSOR && HOTPLUG_CPU && EXPERIMENTAL + depends on !IA64_SGI_SN + default n + ---help--- + Select this option if your platform support physical CPU hotplug. + config ACPI_THERMAL tristate "Thermal Zone" depends on ACPI_PROCESSOR
diff -puN include/linux/cpu.h~processor_drv include/linux/cpu.h diff -puN kernel/cpu.c~processor_drv kernel/cpu.c
drivers/acpi/processor.c renamed from drivers/acpi/processor.c~processor_drv +401 -67
570 lines not on this page · raw message
_
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
Re: [ACPI] PATCH-ACPI based CPU hotplug[5/6]-ACPI processor driver extension
Quoted 19 lines · On Mon, 20 Sep 2004 09:43:52 -0700 Keshavamurthy Anil S wrote:
Changes form previous version
1) Added depends on EXPERIMENTAL in kconfig file---
Name:processor_drv.patch
Status:Tested on 2.6.9-rc2Signed-off-by Anil S Keshavamurthy <[email protected]>Depends:
Version: applies on 2.6.9-rc2
Description:
Extends the processor driver to support ACPI based Physical CPU hotplug.(quoted diff) +7
-0+static int +is_processor_present( + acpi_handle handle) +{ + acpi_status status; + unsigned long sta = 0; +
Review
Quoted 10 lines
(quoted diff) +10
-0+ ACPI_FUNCTION_TRACE("is_processor_present"); + + status = acpi_evaluate_integer(handle, "_STA", NULL, &sta); + if (ACPI_FAILURE(status) || !(sta & ACPI_STA_PRESENT)) { + ACPI_DEBUG_PRINT((ACPI_DB_ERROR, + "Processor Device is not present\n")); + return_VALUE(0); + } + return_VALUE(1); +}
This assumes that a device is not present if acpi_evaluate_integer() returns failure. But, from the ACPI spec, I think we should assume the device is present if the function fails due to a failure in finding _STA method.
I am attaching a patch to fix this. Please see it below.
Thanks,
Keiichiro Tokunaga
Name: cpu_hp_sta_fix.patch
Status: Tested on 2.6.9-rc2
Description:
Fix the evaluation method of _STA in drivers/acpi/processor.c. If a processor object does not have _STA, we should consider it as present.
---
linux-2.6.9-rc2-fix-kei/drivers/acpi/processor.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletion(-)
drivers/acpi/processor.c renamed from drivers/acpi/processor.c~cpu_hp_sta_fix +11 -1
@@ -2551,7 +2551,17 @@ is_processor_present(ACPI_FUNCTION_TRACE ("is_processor_present" ); status =acpi_evaluate_integer (handle,"_STA" ,NULL , &sta); -if (ACPI_FAILURE (status) || !(sta &ACPI_STA_PRESENT )) { +if (ACPI_FAILURE (status)) { +/* Assume device is present if it does not have _STA. */ +if (status ==AE_NOT_FOUND ) +return_VALUE (1 ); +else { +printk (KERN_WARNING "Failed to evaluate _STA.\n" ); +return_VALUE (0 ); + } + } + +if (!(sta &ACPI_STA_PRESENT )) {ACPI_DEBUG_PRINT ((ACPI_DB_ERROR ,"Processor Device is not present\n" ));return_VALUE (0 );
_
Re: PATCH-ACPI based CPU hotplug[5/6]-ACPI processor driver extension
In reply to Keshavamurthy Anil SQuoted 2 lines · Keshavamurthy Anil S
Changes form previous version
1) Added depends on EXPERIMENTAL in kconfig file
Changes from previous version
Added prink for ACPI_NOTIFY_BUS_CHECK and for ACPI_NOTIFY_DEVICE_CHECK based on
the community feedback.
---
Name:processor_drv.patch
Status:Tested on 2.6.9-rc2
Depends:
Version: applies on 2.6.9-rc2
Description:
Extends the processor driver to support ACPI based Physical CPU hotplug.
---
include/linux/cpu.h | 0 kernel/cpu.c | 0 linux-2.6.9-rc2-askeshav/drivers/acpi/Kconfig | 8 linux-2.6.9-rc2-askeshav/drivers/acpi/processor.c | 485 ++++++++++++++++++---- 4 files changed, 424 insertions(+), 69 deletions(-)
drivers/acpi/Kconfig renamed from drivers/acpi/Kconfig~processor_drv +8 -0
@@ -129,6 +129,14 @@ config ACPI_PROCESSOR ACPI C2 and C3 processor states to save power, on systems that support it. +config ACPI_HOTPLUG_CPU + bool "Processor Hotplug (EXPERIMENTAL)" + depends on ACPI_PROCESSOR && HOTPLUG_CPU && EXPERIMENTAL + depends on !IA64_SGI_SN + default n + ---help--- + Select this option if your platform support physical CPU hotplug. + config ACPI_THERMAL tristate "Thermal Zone" depends on ACPI_PROCESSOR
diff -puN include/linux/cpu.h~processor_drv include/linux/cpu.h diff -puN kernel/cpu.c~processor_drv kernel/cpu.c
drivers/acpi/processor.c renamed from drivers/acpi/processor.c~processor_drv +416 -69
589 lines not on this page · raw message
_
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
PATCH-ACPI based CPU hotplug[6/6]-ACPI Container driver
In reply to Keshavamurthy Anil SChanges from previous release:
1) Typo fix- ACPI004 to ACPI0004
2) Added depends on EXPERIMENTAL in Kconfig file
---
Name:container_drv.patch
Status: Tested on 2.6.9-rc1
Depends:
Version: applies on 2.6.9-rc1
Description:
This is the very early version on the Container driver which supports hotplug notifications on ACPI0004, PNP0A05 and PNP0A06 devices.
Changes from previous release:
1) Mergerd the typo fix patch which changes "ACPI004" to "ACPI0004"
---
drivers/acpi/Kconfig renamed from drivers/acpi/Kconfig~container_drv +9 -1
@@ -133,6 +133,7 @@ config ACPI_HOTPLUG_CPU bool "Processor Hotplug (EXPERIMENTAL)" depends on ACPI_PROCESSOR && HOTPLUG_CPU && EXPERIMENTAL depends on !IA64_SGI_SN + select ACPI_CONTAINER default n ---help--- Select this option if your platform support physical CPU hotplug.
@@ -278,5 +279,12 @@ config X86_PM_TIMER kernel logs, and/or you are using this on a notebook which does not yet have an HPET, you should say "Y" here. -endmenu +config ACPI_CONTAINER + tristate "ACPI0004,PNP0A05 and PNP0A06 Container Driver (EXPERIMENTAL)" + depends on ACPI && EXPERIMENTAL + default (ACPI_HOTPLUG_MEMORY || ACPI_HOTPLUG_CPU || ACPI_HOTPLUG_IO) + ---help--- + This is the ACPI generic container driver which supports + ACPI0004, PNP0A05 and PNP0A06 devices +endmenu
drivers/acpi/Makefile renamed from drivers/acpi/Makefile~container_drv +1 -0
@@ -41,6 +41,7 @@ obj-$(CONFIG_ACPI_FAN) += fan.o obj-$(CONFIG_ACPI_PCI) += pci_root.o pci_link.o pci_irq.o pci_bind.o obj-$(CONFIG_ACPI_POWER) += power.o obj-$(CONFIG_ACPI_PROCESSOR) += processor.o +obj-$(CONFIG_ACPI_CONTAINER) += container.o obj-$(CONFIG_ACPI_THERMAL) += thermal.o obj-$(CONFIG_ACPI_SYSTEM) += system.o event.o obj-$(CONFIG_ACPI_DEBUG) += debug.o
include/acpi/container.h new file +13 -0
@@ -0,0 +1,13 @@ +#ifndef __ACPI_CONTAINER_H +#define __ACPI_CONTAINER_H + +#include <linux/kernel.h> + +struct acpi_container { +acpi_handle handle; +unsigned long sun; +int state; +}; + +#endif /* __ACPI_CONTAINER_H */ +
drivers/acpi/container.c new file +341 -0
341 lines not on this page · raw message
_
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
cover NUMA node handling support for ACPI container driver
Quoted 8 lines · Keshavamurthy Anil S
Changes from previous release:
1) Typo fix- ACPI004 to ACPI0004
2) Added depends on EXPERIMENTAL inKconfigfile---
Name:container_drv.patch
Status: Tested on 2.6.9-rc1Signed-off-by Anil S Keshavamurthy <[email protected]>
Quoted 8 lines
Depends:
Version: applies on 2.6.9-rc1
Description:
This is the very early version on the Container driver which supports hotplug notifications on ACPI0004, PNP0A05 and PNP0A06 devices.
Changes from previous release:
1) Mergerd the typo fix patch which changes "ACPI004" to "ACPI0004"
---
I have made a patchset to add 'NUMA node handling support' to your patchset. If a container that is identical to NUMA node is hotplugged, this handles NUMA related stuffs. For instance, creating/deleting sysfs directories and files of node, data structures, and etc...
- numa_hp_base.patch
- numa_hp_ia64.patch
- acpi_numa_hp.patch
- container_for_numa.patch
Status: Tested on 2.6.9-rc2 including your patchset posted earlier.
Thanks,
Keiichiro Tokunaga
PATCH 1/4 Add unregister_node() to drivers/base/node.c
Name: numa_hp_base.patch
Status: Tested on 2.6.9-rc2
Description:
Create unregister_node() that removes corresponding sysfs directory and files from /sys/devices/system/node/ at hot-removal time.
Thanks,
Keiichiro Tokunaga
---
linux-2.6.9-rc2-fix-kei/drivers/base/node.c | 16 +++++++++++++++- linux-2.6.9-rc2-fix-kei/include/linux/node.h | 1 + linux-2.6.9-rc2-fix-kei/mm/page_alloc.c | 2 ++ 3 files changed, 18 insertions(+), 1 deletion(-)
drivers/base/node.c renamed from drivers/base/node.c~numa_hp_base +15 -1
@@ -117,7 +117,7 @@ static SYSDEV_ATTR(numastat, S_IRUGO, no* * Initialize and register the node device. */ -int __init register_node (struct node *node,int num,struct node *parent) +int register_node (struct node *node,int num,struct node *parent) {int error;
@@ -132,6 +132,16 @@ int __init register_node(struct node *no }return error; } +void unregister_node (struct node *node,struct node *parent) +{ +if (node ==NULL ) { +printk ("unregister_node: node is null." ); +return ; + } +sysdev_remove_file (&node->sysdev, &attr_cpumap); +sysdev_remove_file (&node->sysdev, &attr_meminfo); +sysdev_unregister (&node->sysdev); +}int __init register_node_type (void )
@@ -139,3 +149,7 @@ int __init register_node_type(void)return sysdev_class_register (&node_class); }postcore_initcall (register_node_type); + + +EXPORT_SYMBOL (register_node); +EXPORT_SYMBOL (unregister_node);
include/linux/node.h renamed from include/linux/node.h~numa_hp_base +1 -0
@@ -27,6 +27,7 @@ struct node { };extern int register_node (struct node *,int ,struct node *); +extern void unregister_node (struct node *node,struct node *parent);#define to_node (sys_device) container_of(sys_device, struct node, sysdev)
mm/page_alloc.c renamed from mm/page_alloc.c~numa_hp_base +2 -0
@@ -14,6 +14,7 @@* (lots of bits borrowed from Ingo Molnar & Andrew Morton) */ +#include <linux/module.h> #include <linux/config.h> #include <linux/stddef.h> #include <linux/mm.h>
@@ -44,6 +45,7 @@ int sysctl_lower_zone_protection = 0;EXPORT_SYMBOL (totalram_pages);EXPORT_SYMBOL (nr_swap_pages); +EXPORT_SYMBOL (node_online_map);/* * Used by page_zone() to look up the address of the struct zone whose
_
Re: [Lhns-devel] [PATCH][1/4] Add unregister_node() to drivers/base/node.c
drivers/base/node.c static SYSDEV_ATTR(numastat, S_IRUGO, no · line 120
Quoted 2 lines · Keiichiro Tokunaga
drivers/base/node.c renamed from drivers/base/node.c~numa_hp_base +1
-1-int __init register_node (struct node *node,int num,struct node *parent) +int register_node (struct node *node,int num,struct node *parent)
__devinit, please.
-- Dave
Re: [Lhns-devel] [PATCH][1/4] Add unregister_node() to drivers/base/node.c
Quoted 5 lines · On Thu, 23 Sep 2004 09:43:16 -0700 Dave Hansen wrote:
Review
Quoted 2 lines · Keiichiro Tokunaga
(quoted diff) +1
-1-int __init register_node(struct node *node, int num, struct node *parent) +int register_node(struct node *node, int num, struct node *parent)
__devinit, please.
Exactly. Thanks for looking.
I have refreshed the patch. Anil, please replace the old one with this.
Thanks,
Keiichiro Tokunaga
Name: numa_hp_base.patch
Status: Tested on 2.6.9-rc2
Description:
Create unregister_node() to remove corresponding sysfs directory and files from /sys/devices/system/node/.
---
linux-2.6.9-rc2-fix-kei/drivers/base/node.c | 19 +++++++++++++++++-- linux-2.6.9-rc2-fix-kei/include/linux/node.h | 3 ++- linux-2.6.9-rc2-fix-kei/mm/page_alloc.c | 2 ++ 3 files changed, 21 insertions(+), 3 deletions(-)
drivers/base/node.c renamed from drivers/base/node.c~numa_hp_base +17 -2
@@ -117,7 +117,7 @@ static SYSDEV_ATTR(numastat, S_IRUGO, no* * Initialize and register the node device. */ -int __init register_node (struct node *node,int num,struct node *parent) +int __devinit register_node (struct node *node,int num,struct node *parent) {int error;
@@ -133,9 +133,24 @@ int __init register_node(struct node *noreturn error; } +void __devexit unregister_node(struct node *node, struct node *parent) +{ +if (node ==NULL ) { +printk ("unregister_node: node is null." ); +return ; + } +sysdev_remove_file (&node->sysdev, &attr_cpumap); +sysdev_remove_file (&node->sysdev, &attr_meminfo); +sysdev_unregister (&node->sysdev); +} -int __init register_node_type (void ) + +static int __init register_node_type (void ) {return sysdev_class_register (&node_class); }postcore_initcall (register_node_type); + + +EXPORT_SYMBOL (register_node); +EXPORT_SYMBOL (unregister_node);
include/linux/node.h renamed from include/linux/node.h~numa_hp_base +2 -1
@@ -26,7 +26,8 @@ struct node {struct sys_device sysdev; }; -extern int register_node (struct node *,int ,struct node *); +extern int __devinit register_node (struct node *,int ,struct node *); +extern void __devexit unregister_node(struct node *node, struct node *parent);#define to_node (sys_device) container_of(sys_device, struct node, sysdev)
mm/page_alloc.c renamed from mm/page_alloc.c~numa_hp_base +2 -0
@@ -14,6 +14,7 @@* (lots of bits borrowed from Ingo Molnar & Andrew Morton) */ +#include <linux/module.h> #include <linux/config.h> #include <linux/stddef.h> #include <linux/mm.h>
@@ -44,6 +45,7 @@ int sysctl_lower_zone_protection = 0;EXPORT_SYMBOL (totalram_pages);EXPORT_SYMBOL (nr_swap_pages); +EXPORT_SYMBOL (node_online_map);/* * Used by page_zone() to look up the address of the struct zone whose
_
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
Re: [PATCH][1/4] Add unregister_node() to drivers/base/node.c
In reply to Keiichiro Tokunagadrivers/base/node.c static SYSDEV_ATTR(numastat, S_IRUGO, no · line 120
Quoted 3 lines · Keiichiro Tokunaga
drivers/base/node.c renamed from drivers/base/node.c~numa_hp_base +1
-1-int __init register_node (struct node *node,int num,struct node *parent) +int register_node (struct node *node,int num,struct node *parent)
__devinit please
Quoted 1 line
+void
unregister_node(struct node *node, struct node *parent)
unregister_node is required only for hotplug case. Please hide this function under suitable #ifdef's, say this is only required if CONFIG_HOTPLUG is enabled.
drivers/base/node.c int __init register_node(struct node *no · line 142
Quoted 2 lines
drivers/base/node.c renamed from drivers/base/node.c~numa_hp_base +2
-0+sysdev_remove_file (&node->sysdev, &attr_cpumap); +sysdev_remove_file (&node->sysdev, &attr_meminfo);
add sysdev_remove_file(&node->sysdev, &attr_numastat);
Quoted 1 line
+EXPORT_SYMBOL(node_online_map);
Why do you need this in this patch?
Re: [PATCH][1/4] Add unregister_node() to drivers/base/node.c
Quoted 1 line · On Mon, 27 Sep 2004 11:52:44 -0700 Keshavamurthy Anil S wrote:
On Fri, Sep 24, 2004 at 01:31:23AM +0900, Keiichiro Tokunaga wrote:
Thanks for the comments!
Quoted 4 lines
Review
Quoted 2 lines
(quoted diff) +1
-1-int __init register_node(struct node *node, int num, struct node *parent) +int register_node(struct node *node, int num, struct node *parent)
__devinitplease
Oh, yes. I got the same comments from Dave and posted an updated
patch fixing the issue.
Quoted 4 lines
Quoted 1 line
+void
unregister_node(struct node *node, struct node *parent)
unregister_nodeis required only for hotplug case. Please hide this function under suitable #ifdef's, say this is only required ifCONFIG_HOTPLUGis enabled.
That's right. I enclosed the function with #ifdef CONFIG_HOTPLUG.
Quoted 4 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ sysdev_remove_file(&node->sysdev, &attr_cpumap); + sysdev_remove_file(&node->sysdev, &attr_meminfo);add
sysdev_remove_file(&node->sysdev, &attr_numastat);
I added.
Quoted 2 lines
Quoted 1 line
+EXPORT_SYMBOL(node_online_map);
Why do you need this in this patch?
Sorry, it's a stuff that I forgot to remove... so it's not needed. I removed it.
I am attaching an updated patch. Please see it below.
Thanks!
Keiichiro Tokunaga
Name: numa_hp_base.patch
Status: Tested on 2.6.9-rc2
Description:
Create unregister_node() to remove corresponding sysfs directory and files from /sys/devices/system/node/.
---
linux-2.6.9-rc2-092704-kei/drivers/base/node.c | 21 +++++++++++++++++++-- linux-2.6.9-rc2-092704-kei/include/linux/node.h | 4 +++- 2 files changed, 22 insertions(+), 3 deletions(-)
drivers/base/node.c renamed from drivers/base/node.c~numa_hp_base +19 -2
@@ -117,7 +117,7 @@ static SYSDEV_ATTR(numastat, S_IRUGO, no* * Initialize and register the node device. */ -int __init register_node (struct node *node,int num,struct node *parent) +int __devinit register_node (struct node *node,int num,struct node *parent) {int error;
@@ -133,9 +133,26 @@ int __init register_node(struct node *noreturn error; } +#ifdef CONFIG_HOTPLUG +void __devexit unregister_node(struct node *node, struct node *parent) +{ +if (node ==NULL ) { +printk ("unregister_node: node is null." ); +return ; + } +sysdev_remove_file (&node->sysdev, &attr_cpumap); +sysdev_remove_file (&node->sysdev, &attr_meminfo); +sysdev_remove_file (&node->sysdev, &attr_numastat); +sysdev_unregister (&node->sysdev); +} +#endif /* CONFIG_HOTPLUG */ -int __init register_node_type (void ) +static int __init register_node_type (void ) {return sysdev_class_register (&node_class); }postcore_initcall (register_node_type); + + +EXPORT_SYMBOL (register_node); +EXPORT_SYMBOL (unregister_node);
include/linux/node.h renamed from include/linux/node.h~numa_hp_base +3 -1
@@ -21,12 +21,14 @@#include <linux/sysdev.h> #include <linux/cpumask.h> +#include <linux/module.h> struct node {struct sys_device sysdev; }; -extern int register_node (struct node *,int ,struct node *); +extern int __devinit register_node (struct node *,int ,struct node *); +extern void __devexit unregister_node(struct node *node, struct node *parent);#define to_node (sys_device) container_of(sys_device, struct node, sysdev)
_
PATCH 2/4 Add arch_register_node() for ia64
In reply to Keiichiro TokunagaName: numa_hp_ia64.patch
Status: Tested on 2.6.9-rc2
Description:
Add arch_register_node() to arch/ia64/kernel/topology.c. The topology.c has been introduced by Anil (Intel).
Thanks,
Keiichiro Tokunaga
---
linux-2.6.9-rc2-fix-kei/arch/ia64/kernel/acpi.c | 1 + linux-2.6.9-rc2-fix-kei/arch/ia64/kernel/topology.c | 18 +++++++++++++++--- linux-2.6.9-rc2-fix-kei/include/asm-ia64/numa.h | 3 ++- 3 files changed, 18 insertions(+), 4 deletions(-)
arch/ia64/kernel/acpi.c renamed from arch/ia64/kernel/acpi.c~numa_hp_ia64 +1 -0
@@ -362,6 +362,7 @@ int __devinitdata pxm_to_nid_map[MAX_PXMint __initdata nid_to_pxm_map[MAX_NUMNODES ];static struct acpi_table_slit __initdata *slit_table; +EXPORT_SYMBOL (pxm_to_nid_map);/* * ACPI 2.0 SLIT (System Locality Information Table) * http://devresource.hp.com/devresource/Docs/TechPapers/IA64/slit.pdf
arch/ia64/kernel/topology.c renamed from arch/ia64/kernel/topology.c~numa_hp_ia64 +15 -3
@@ -21,8 +21,9 @@#include <asm/mmzone.h> #include <asm/numa.h> #include <asm/cpu.h> -#ifdef CONFIG_NUMA +#include <asm/numa.h> +static struct node *sysfs_nodes;#endif static struct ia64_cpu *sysfs_cpus;
@@ -37,6 +38,18 @@ int arch_register_cpu(int num)return register_cpu (&sysfs_cpus[num].cpu, num, parent); } +#ifdef CONFIG_NUMA +int arch_register_node (int num) { +return register_node (&sysfs_nodes[num],num,0 ); +} +int arch_unregister_node (int num) { +unregister_node (&sysfs_nodes[num],0 ); +return 0 ; +} + +EXPORT_SYMBOL (arch_register_node); +EXPORT_SYMBOL (arch_unregister_node); +#endif /*CONFIG_NUMA*/ #ifdef CONFIG_HOTPLUG_CPU
@@ -69,7 +82,7 @@ static int __init topology_init(void)memset (sysfs_nodes,0 ,sizeof (struct node ) *MAX_NUMNODES );for (i =0 ; i < numnodes; i++) -if ((err =register_node (&sysfs_nodes[i], i,0 ))) +if ((err =arch_register_node (i))) goto out;#endif
@@ -86,5 +99,4 @@ static int __init topology_init(void) out:return err; } -__initcall (topology_init);
include/asm-ia64/numa.h renamed from include/asm-ia64/numa.h~numa_hp_ia64 +2 -1
@@ -65,8 +65,9 @@ extern int paddr_to_nid(unsigned long pa#define local_nodeid (cpu_to_node_map[smp_processor_id()]) +extern int arch_register_node (int num); +extern int arch_unregister_node (int num);#else /* !CONFIG_NUMA */ -#define paddr_to_nid (addr) 0#endif /* CONFIG_NUMA */
_
PATCH 3/4 Add hotplug support to drivers/acpi/numa.c
In reply to Keiichiro TokunagaName: acpi_numa_hp.patch
Status: Tested on 2.6.9-rc2
Description:
Add hotplug support to drivers/acpi/numa.c.
Thanks,
Keiichiro Tokunaga
---
linux-2.6.9-rc2-fix-kei/drivers/acpi/numa.c | 267 ++++++++++++++++++++++++++++ linux-2.6.9-rc2-fix-kei/include/acpi/numa.h | 30 +++ 2 files changed, 297 insertions(+)
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_numa_hp +267 -0
@@ -31,6 +31,7 @@#include <linux/acpi.h> #include <acpi/acpi_bus.h> #include <acpi/acmacros.h> +#include <acpi/numa.h> #define ACPI_NUMA 0x80000000#define _COMPONENT ACPI_NUMA
@@ -214,3 +215,269 @@ acpi_get_pxm(acpi_handle h)return -1 ; }EXPORT_SYMBOL (acpi_get_pxm); + + +#if ( defined(CONFIG_ACPI_CONTAINER_MODULE ) || defined(CONFIG_ACPI_CONTAINER ) ) && defined(CONFIG_HOTPLUG ) + +static int nid2pxm (int nid) +{ +int i; + +if ((nid <0 ) || (nid >=MAX_NUMNODES )) +return -1 ; + +for (i=0 ; i <MAX_PXM_DOMAINS ; i++) { +if ( pxm_to_nid_map[i] == nid ) +return i; + } + +return -1 ; +} + +void +acpi_numa_data_handler (acpi_handle handle,u32 function,void *context) +{ +return ; +} + +int is_numa_node_device (acpi_handle handle) +{ +acpi_status status; +struct acpi_numa_node *data=NULL ; + + status =acpi_get_data (handle, acpi_numa_data_handler, (void **)&data); +if (ACPI_FAILURE (status)) +return 0 ; +else +return 1 ; +} + +int acpi_get_numa_nodeid (int pxm) +{ +if (pxm <0 || pxm >=MAX_PXM_DOMAINS ) +return -EINVAL ; + +return pxm_to_nid_map[pxm]; +} +EXPORT_SYMBOL (acpi_get_numa_nodeid); + +static void +set_nodeid (int pxm,int nid) +{ +if (pxm_to_nid_map[pxm] >=0 ) { +printk (KERN_INFO "PXM <%d> already has a nid <%d>.\n" , + pxm_to_nid_map[pxm], pxm); +return ; + } + +if (nid >=MAX_NUMNODES ) { +printk (KERN_ERR "nid <%d> is too big. Range: 0-%d\n" , + nid,MAX_NUMNODES -1 ); +return ; + } + + pxm_to_nid_map[pxm] = nid; +} + +static void unget_nodeid (int nid) +{ +#ifdef PXM_FIX_NODEID +int pxm =nid2pxm (nid); +if (pxm <0 ) +return ; + pxm_to_nid_map[pxm] =-1 ; +#endif +} + +static int +allocate_nodeid (int pxm) +{ +int i; + +#ifndef PXM_FIX_NODEID +if (pxm_to_nid_map[pxm] >=0 ) +return pxm_to_nid_map[pxm]; +#endif +for (i=0 ;i <MAX_NUMNODES ; i++) { +if (nid2pxm (i) <0 ) +return i; + } + +printk (KERN_ERR "Failed to allocate nid for PXM <%d>\n" , pxm); +return -1 ; +} + +static acpi_status +find_processor (acpi_handle handle,u32 lvl,void *context,void **rv) +{ +int **cntp = (int **)rv; + +ACPI_FUNCTION_TRACE ("find_processor" ); + + ++(**cntp); + +return_ACPI_STATUS (AE_OK ); +} + +void acpi_numa_node_add (acpi_handle handle) +{ +acpi_status status; +struct acpi_numa_node *data=NULL ; + +ACPI_FUNCTION_TRACE ("acpi_numa_node_add" ); + + status =acpi_get_data (handle, acpi_numa_data_handler, (void **)&data); +if (ACPI_FAILURE (status)) + return_VOID; + +if (data->pxm <0 ) { +printk (KERN_ERR "Container does not have PXM.\n" ); + return_VOID; + } + +arch_register_node (data->nid); + + return_VOID; +} + +void acpi_numa_node_remove (acpi_handle handle) +{ +acpi_status status; +struct acpi_numa_node *data=NULL ; +int nid; + +ACPI_FUNCTION_TRACE ("acpi_numa_node_remove" ); + + status =acpi_get_data (handle, acpi_numa_data_handler, (void **)&data); +if (ACPI_FAILURE (status) || !data) + return_VOID; + + nid = data->nid; +if (nid <0 ) { +printk (KERN_ERR "Invalid nid %d\n" , nid); + return_VOID; + } + +arch_unregister_node (nid); +unget_nodeid (nid); +acpi_numa_node_data_detach (handle); + + return_VOID; +} + +void acpi_numa_node_data_detach (acpi_handle handle) +{ +struct acpi_numa_node *data=NULL ; +acpi_status status; + +ACPI_FUNCTION_TRACE ("acpi_numa_node_data_detach" ); + + status =acpi_get_data (handle, acpi_numa_data_handler, (void **)&data); +if (ACPI_FAILURE (status) || (data ==NULL )) + return_VOID; + + status =acpi_detach_data (handle, acpi_numa_data_handler); +if (ACPI_FAILURE (status)) { +printk (KERN_ERR "Failed to detach NUMA node data.\n" ); + return_VOID; + } + +kfree (data); +ACPI_DEBUG_PRINT ((ACPI_DB_INFO ,"NUMA node data is detached.\n" )); + return_VOID; +} + +void acpi_numa_node_init (acpi_handle handle) +{ +int pxm; +acpi_status status; +struct acpi_numa_node *data; +int _cnt=0 ; +int *cnt=&_cnt; +struct acpi_device *node_dev=NULL ; + +ACPI_FUNCTION_TRACE ("acpi_numa_node_init" ); + +if (acpi_bus_get_device (handle, &node_dev)) { +printk (KERN_ERR "Unknown handle.\n" ); + return_VOID; + } + + pxm =acpi_get_pxm (handle); +if (pxm <0 ) { +ACPI_DEBUG_PRINT ((ACPI_DB_WARN ,"PXM was not found.\n" )); + return_VOID; + } + + data =kmalloc (sizeof (struct acpi_numa_node ),GFP_KERNEL ); +if (!data) { +printk (KERN_ERR "Not enough memory.\n" ); + return_VOID; + } + + data->handle = handle; + data->pxm = pxm; + data->nid =-1 ; + +acpi_walk_namespace (ACPI_TYPE_PROCESSOR , + handle, + (u32 )1 , + find_processor, + data, + (void **)&cnt); +/* +* TBD: Check nid of memory object +* paddr_to_node[] (include/asm-ia64/numa.h) +*/ +if (! _cnt) { +ACPI_DEBUG_PRINT ((ACPI_DB_INFO , +"nid of <%s> is not detected.\n" , +acpi_device_bid (node_dev))); + goto cancel; + } + +if (pxm_to_nid_map[pxm] <0 ) { +int nid =allocate_nodeid (pxm); +ACPI_DEBUG_PRINT ((ACPI_DB_INFO , +"nid <%d> is allocated for PXM <%d>.\n" , + nid, data->pxm)); +if (nid <1 ) { +/* "node 0" is a fixed ID. */ +printk (KERN_ERR "Cannot get nid.\n" ); + return_VOID; + } + data->nid = nid; +set_nodeid (pxm, nid); + }else { + data->nid = pxm_to_nid_map[pxm]; + } + + + status =acpi_attach_data (handle, acpi_numa_data_handler, data); +if (ACPI_FAILURE (status)) { +printk (KERN_ERR "Failed to attach NUMA data for <%s>.\n" , +acpi_device_bid (node_dev)); + goto cancel; + } + +printk (KERN_INFO "Container <%s> is NUMA node.\n" , +acpi_device_bid (node_dev)); +ACPI_DEBUG_PRINT ((ACPI_DB_INFO , +"Initialized: Container<%s> PXM=%d nid=%d\n" , +acpi_device_bid (node_dev), pxm, data->nid)); + return_VOID; + +cancel: +if (data) +kfree (data); + return_VOID; +} + +EXPORT_SYMBOL (acpi_numa_node_init); +EXPORT_SYMBOL (acpi_numa_node_add); +EXPORT_SYMBOL (acpi_numa_node_remove); +EXPORT_SYMBOL (acpi_numa_node_data_detach); +EXPORT_SYMBOL (acpi_numa_data_handler); +EXPORT_SYMBOL (is_numa_node_device); + +#endif /* defined(CONFIG_ACPI_CONTAINER) && defined(CONFIG_HOTPLUG) */
include/acpi/numa.h new file +30 -0
@@ -0,0 +1,30 @@ +#ifndef _ACPI_NUMA_H_ +#define _ACPI_NUMA_H_ + +#include <linux/config.h> +#include <linux/kernel.h> +#include <linux/acpi.h> +#include <asm/acpi.h> +#include <acpi/acpixf.h> + +#if defined(CONFIG_ACPI_CONTAINER ) || defined(CONFIG_ACPI_CONTAINER_MODULE ) +#include <linux/numa.h> +struct acpi_numa_node { +acpi_handle handle; +int pxm; +int nid; +}; + +#ifndef MAX_PXM_DOMAINS +#define MAX_PXM_DOMAINS (256) +#endif +extern void acpi_numa_node_init (acpi_handle handle); +extern void acpi_numa_node_add (acpi_handle handle); +extern void acpi_numa_node_remove (acpi_handle handle); +extern void acpi_numa_data_handler (acpi_handle handle,u32 function,void *context); +extern void acpi_numa_node_data_detach (acpi_handle handle); +extern int is_numa_node_device (acpi_handle handle); +extern int acpi_numa_node_add_post (acpi_handle handle); +extern int acpi_numa_node_remove_request (acpi_handle handle); +#endif /* CONFIG_ACPI_CONTAINER */ +#endif
_
Re: [PATCH][3/4] Add hotplug support to drivers/acpi/numa.c
Quoted 6 lines · On Fri, 24 Sep 2004 01:32:55 +0900 Keiichiro Tokunaga wrote:
Name: acpi_numa_hp.patch
Status: Tested on 2.6.9-rc2Signed-off-by Keiichiro Tokunaga <[email protected]>Description:
Add hotplug support todrivers/acpi/numa.c.
Sorry, I found a bug in the printk's message.
Review
Quoted 5 lines
(quoted diff) +5
-0+ if (pxm_to_nid_map[pxm] >= 0) { + printk(KERN_INFO"PXM <%d> already has a nid <%d>.\n", + pxm_to_nid_map[pxm], pxm); + return ; + }
The second and third arguments should change place with each other like,
Review
Quoted 2 lines
(quoted diff) +2
-0+ printk(KERN_INFO"PXM <%d> already has a nid <%d>.\n", + pxm, pxm_to_nid_map[pxm]);
I am attaching an updated patch. Anil, please include it instead of the old one.
Thanks,
Keiichiro Tokunaga
Status: Tested on 2.6.9-rc2
---
linux-2.6.9-rc2-092704-kei/drivers/acpi/numa.c | 267 +++++++++++++++++++++++++ linux-2.6.9-rc2-092704-kei/include/acpi/numa.h | 30 ++ 2 files changed, 297 insertions(+)
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_numa_hp +267 -0
@@ -31,6 +31,7 @@#include <linux/acpi.h> #include <acpi/acpi_bus.h> #include <acpi/acmacros.h> +#include <acpi/numa.h> #define ACPI_NUMA 0x80000000#define _COMPONENT ACPI_NUMA
@@ -212,3 +213,269 @@ acpi_get_pxm(acpi_handle handle)return -1 ; }EXPORT_SYMBOL (acpi_get_pxm); + + +#if ( defined(CONFIG_ACPI_CONTAINER_MODULE ) || defined(CONFIG_ACPI_CONTAINER ) ) && defined(CONFIG_HOTPLUG ) + +static int nid2pxm (int nid) +{ +int i; + +if ((nid <0 ) || (nid >=MAX_NUMNODES )) +return -1 ; + +for (i=0 ; i <MAX_PXM_DOMAINS ; i++) { +if ( pxm_to_nid_map[i] == nid ) +return i; + } + +return -1 ; +} + +void +acpi_numa_data_handler (acpi_handle handle,u32 function,void *context) +{ +return ; +} + +int is_numa_node_device (acpi_handle handle) +{ +acpi_status status; +struct acpi_numa_node *data=NULL ; + + status =acpi_get_data (handle, acpi_numa_data_handler, (void **)&data); +if (ACPI_FAILURE (status)) +return 0 ; +else +return 1 ; +} + +int acpi_get_numa_nodeid (int pxm) +{ +if (pxm <0 || pxm >=MAX_PXM_DOMAINS ) +return -EINVAL ; + +return pxm_to_nid_map[pxm]; +} +EXPORT_SYMBOL (acpi_get_numa_nodeid); + +static void +set_nodeid (int pxm,int nid) +{ +if (pxm_to_nid_map[pxm] >=0 ) { +printk (KERN_INFO "PXM <%d> already has a nid <%d>.\n" , + pxm, pxm_to_nid_map[pxm]); +return ; + } + +if (nid >=MAX_NUMNODES ) { +printk (KERN_ERR "nid <%d> is too big. Range: 0-%d\n" , + nid,MAX_NUMNODES -1 ); +return ; + } + + pxm_to_nid_map[pxm] = nid; +} + +static void unget_nodeid (int nid) +{ +#ifdef PXM_FIX_NODEID +int pxm =nid2pxm (nid); +if (pxm <0 ) +return ; + pxm_to_nid_map[pxm] =-1 ; +#endif +} + +static int +allocate_nodeid (int pxm) +{ +int i; + +#ifndef PXM_FIX_NODEID +if (pxm_to_nid_map[pxm] >=0 ) +return pxm_to_nid_map[pxm]; +#endif +for (i=0 ;i <MAX_NUMNODES ; i++) { +if (nid2pxm (i) <0 ) +return i; + } + +printk (KERN_ERR "Failed to allocate nid for PXM <%d>\n" , pxm); +return -1 ; +} + +static acpi_status +find_processor (acpi_handle handle,u32 lvl,void *context,void **rv) +{ +int **cntp = (int **)rv; + +ACPI_FUNCTION_TRACE ("find_processor" ); + + ++(**cntp); + +return_ACPI_STATUS (AE_OK ); +} + +void acpi_numa_node_add (acpi_handle handle) +{ +acpi_status status; +struct acpi_numa_node *data=NULL ; + +ACPI_FUNCTION_TRACE ("acpi_numa_node_add" ); + + status =acpi_get_data (handle, acpi_numa_data_handler, (void **)&data); +if (ACPI_FAILURE (status)) + return_VOID; + +if (data->pxm <0 ) { +printk (KERN_ERR "Container does not have PXM.\n" ); + return_VOID; + } + +arch_register_node (data->nid); + + return_VOID; +} + +void acpi_numa_node_remove (acpi_handle handle) +{ +acpi_status status; +struct acpi_numa_node *data=NULL ; +int nid; + +ACPI_FUNCTION_TRACE ("acpi_numa_node_remove" ); + + status =acpi_get_data (handle, acpi_numa_data_handler, (void **)&data); +if (ACPI_FAILURE (status) || !data) + return_VOID; + + nid = data->nid; +if (nid <0 ) { +printk (KERN_ERR "Invalid nid %d\n" , nid); + return_VOID; + } + +arch_unregister_node (nid); +unget_nodeid (nid); +acpi_numa_node_data_detach (handle); + + return_VOID; +} + +void acpi_numa_node_data_detach (acpi_handle handle) +{ +struct acpi_numa_node *data=NULL ; +acpi_status status; + +ACPI_FUNCTION_TRACE ("acpi_numa_node_data_detach" ); + + status =acpi_get_data (handle, acpi_numa_data_handler, (void **)&data); +if (ACPI_FAILURE (status) || (data ==NULL )) + return_VOID; + + status =acpi_detach_data (handle, acpi_numa_data_handler); +if (ACPI_FAILURE (status)) { +printk (KERN_ERR "Failed to detach NUMA node data.\n" ); + return_VOID; + } + +kfree (data); +ACPI_DEBUG_PRINT ((ACPI_DB_INFO ,"NUMA node data is detached.\n" )); + return_VOID; +} + +void acpi_numa_node_init (acpi_handle handle) +{ +int pxm; +acpi_status status; +struct acpi_numa_node *data; +int _cnt=0 ; +int *cnt=&_cnt; +struct acpi_device *node_dev=NULL ; + +ACPI_FUNCTION_TRACE ("acpi_numa_node_init" ); + +if (acpi_bus_get_device (handle, &node_dev)) { +printk (KERN_ERR "Unknown handle.\n" ); + return_VOID; + } + + pxm =acpi_get_pxm (handle); +if (pxm <0 ) { +ACPI_DEBUG_PRINT ((ACPI_DB_WARN ,"PXM was not found.\n" )); + return_VOID; + } + + data =kmalloc (sizeof (struct acpi_numa_node ),GFP_KERNEL ); +if (!data) { +printk (KERN_ERR "Not enough memory.\n" ); + return_VOID; + } + + data->handle = handle; + data->pxm = pxm; + data->nid =-1 ; + +acpi_walk_namespace (ACPI_TYPE_PROCESSOR , + handle, + (u32 )1 , + find_processor, + data, + (void **)&cnt); +/* +* TBD: Check nid of memory object +* paddr_to_node[] (include/asm-ia64/numa.h) +*/ +if (! _cnt) { +ACPI_DEBUG_PRINT ((ACPI_DB_INFO , +"nid of <%s> is not detected.\n" , +acpi_device_bid (node_dev))); + goto cancel; + } + +if (pxm_to_nid_map[pxm] <0 ) { +int nid =allocate_nodeid (pxm); +ACPI_DEBUG_PRINT ((ACPI_DB_INFO , +"nid <%d> is allocated for PXM <%d>.\n" , + nid, data->pxm)); +if (nid <1 ) { +/* "node 0" is a fixed ID. */ +printk (KERN_ERR "Cannot get nid.\n" ); + return_VOID; + } + data->nid = nid; +set_nodeid (pxm, nid); + }else { + data->nid = pxm_to_nid_map[pxm]; + } + + + status =acpi_attach_data (handle, acpi_numa_data_handler, data); +if (ACPI_FAILURE (status)) { +printk (KERN_ERR "Failed to attach NUMA data for <%s>.\n" , +acpi_device_bid (node_dev)); + goto cancel; + } + +printk (KERN_INFO "Container <%s> is NUMA node.\n" , +acpi_device_bid (node_dev)); +ACPI_DEBUG_PRINT ((ACPI_DB_INFO , +"Initialized: Container<%s> PXM=%d nid=%d\n" , +acpi_device_bid (node_dev), pxm, data->nid)); + return_VOID; + +cancel: +if (data) +kfree (data); + return_VOID; +} + +EXPORT_SYMBOL (acpi_numa_node_init); +EXPORT_SYMBOL (acpi_numa_node_add); +EXPORT_SYMBOL (acpi_numa_node_remove); +EXPORT_SYMBOL (acpi_numa_node_data_detach); +EXPORT_SYMBOL (acpi_numa_data_handler); +EXPORT_SYMBOL (is_numa_node_device); + +#endif /* defined(CONFIG_ACPI_CONTAINER) && defined(CONFIG_HOTPLUG) */
include/acpi/numa.h new file +30 -0
@@ -0,0 +1,30 @@ +#ifndef _ACPI_NUMA_H_ +#define _ACPI_NUMA_H_ + +#include <linux/config.h> +#include <linux/kernel.h> +#include <linux/acpi.h> +#include <asm/acpi.h> +#include <acpi/acpixf.h> + +#if defined(CONFIG_ACPI_CONTAINER ) || defined(CONFIG_ACPI_CONTAINER_MODULE ) +#include <linux/numa.h> +struct acpi_numa_node { +acpi_handle handle; +int pxm; +int nid; +}; + +#ifndef MAX_PXM_DOMAINS +#define MAX_PXM_DOMAINS (256) +#endif +extern void acpi_numa_node_init (acpi_handle handle); +extern void acpi_numa_node_add (acpi_handle handle); +extern void acpi_numa_node_remove (acpi_handle handle); +extern void acpi_numa_data_handler (acpi_handle handle,u32 function,void *context); +extern void acpi_numa_node_data_detach (acpi_handle handle); +extern int is_numa_node_device (acpi_handle handle); +extern int acpi_numa_node_add_post (acpi_handle handle); +extern int acpi_numa_node_remove_request (acpi_handle handle); +#endif /* CONFIG_ACPI_CONTAINER */ +#endif
_
Re: [PATCH][3/4] Add hotplug support to drivers/acpi/numa.c
In reply to Keiichiro TokunagaQuoted 1 line · Keiichiro Tokunaga
+void
acpi_numa_node_init(acpi_handle handle)
Why is this function returning void? I expect
this to return int, what do you think?
drivers/acpi/numa.c acpi_get_pxm(acpi_handle h) · line 404
Quoted 5 lines
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_numa_hp +5
-0+ +if (acpi_bus_get_device (handle, &node_dev)) { +printk (KERN_ERR "Unknown handle.\n" ); + return_VOID; + }
Why do you need to call acpi_bus_get_device?
drivers/acpi/numa.c acpi_get_pxm(acpi_handle h) · line 427
Quoted 6 lines
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_numa_hp +6
-0+acpi_walk_namespace (ACPI_TYPE_PROCESSOR , + handle, + (u32 )1 , + find_processor, + data, + (void **)&cnt);
Why are you looking for processor device here?
Please remove this acpi_walk_namespace function.
include/acpi/numa.h line 20
Quoted 5 lines
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_numa_hp +1
-0+/* diff -puN
/dev/nullinclude/acpi/numa.hinclude/acpi/numa.h new file +3
-0+#ifndef MAX_PXM_DOMAINS +#define MAX_PXM_DOMAINS (256) +#endif
Why defining it again, It is already defined in asm-ia64/acpi.h file
Quoted 2 lines
_
Re: [PATCH][3/4] Add hotplug support to drivers/acpi/numa.c
Quoted 10 lines · On Mon, 27 Sep 2004 13:06:16 -0700 Keshavamurthy Anil S wrote:
Quoted 1 line · Keiichiro Tokunaga
+void
acpi_numa_node_init(acpi_handle handle)Why is this function returning void? I expect
this to return int, what do you think?drivers/acpi/numa.c acpi_get_pxm(acpi_handle h) · line 404
Quoted 5 lines
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_numa_hp +5
-0+ +if (acpi_bus_get_device (handle, &node_dev)) { +printk (KERN_ERR "Unknown handle.\n" ); + return_VOID; + }Why do you need to call
acpi_bus_get_device?
I wrote it for printk()s and ACPI_DEBUG_PRINT() to log.
if (! _cnt) {
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"nid of <%s> is not detected.\n",
acpi_device_bid(node_dev)));
goto cancel;
}
...
status = acpi_attach_data(handle, acpi_numa_data_handler, data);
if (ACPI_FAILURE(status)) {
printk(KERN_ERR"Failed to attach NUMA data for <%s>.\n",
acpi_device_bid(node_dev));
goto cancel;
}
printk(KERN_INFO"Container <%s> is NUMA node.\n",
acpi_device_bid(node_dev));Quoted 8 lines
drivers/acpi/numa.c acpi_get_pxm(acpi_handle h) · line 427
Quoted 6 lines
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_numa_hp +6
-0+acpi_walk_namespace (ACPI_TYPE_PROCESSOR , + handle, + (u32 )1 , + find_processor, + data, + (void **)&cnt);Why are you looking for processor device here?
Please remove thisacpi_walk_namespacefunction.
The reason why the acpi_walk_namespace() is used here was to find a container object which is identical to a NUMA node. My code was assuming that a container having CPU and/or memory was NUMA node sinece the current Linux seemed to assume so.
Quoted 6 lines
include/acpi/numa.h line 20
Quoted 5 lines
drivers/acpi/numa.c renamed from drivers/acpi/numa.c~acpi_numa_hp +1
-0+/* diff -puN
/dev/nullinclude/acpi/numa.hinclude/acpi/numa.h new file +3
-0+#ifndef MAX_PXM_DOMAINS +#define MAX_PXM_DOMAINS (256) +#endif Why defining it again, It is already defined in
asm-ia64/acpi.hfile
Sorry, that's a stuff that I forgot to remove. I will remove it.
Thanks,
Keiichiro Tokunaga
PATCH 4/4 Add NUMA node handling to the container driver
In reply to Keiichiro TokunagaName: container_for_numa.patch
Status: Tested on 2.6.9-rc2
Description:
Add NUMA node handling to the container driver.
Thanks,
Keiichiro Tokunaga
---
linux-2.6.9-rc2-fix-kei/drivers/acpi/container.c | 11 +++++++++++ linux-2.6.9-rc2-fix-kei/include/acpi/container.h | 15 ++++++++++++++- 2 files changed, 25 insertions(+), 1 deletion(-)
drivers/acpi/container.c renamed from drivers/acpi/container.c~container_for_numa +11 -0
@@ -104,6 +104,8 @@ acpi_container_add(struct acpi_device *d container =kmalloc (sizeof (struct acpi_container ),GFP_KERNEL );if (!container)return_VALUE (-ENOMEM ); + +container_numa_init (device->handle);memset (container,0 ,sizeof (struct acpi_container )); container->handle = device->handle;
@@ -123,6 +125,14 @@ acpi_container_remove(struct acpi_device {acpi_status status =AE_OK ;struct acpi_container *pc =NULL ; +if (type ==ACPI_BUS_REMOVAL_EJECT ) { +if (!device->flags.ejectable) +return (-EINVAL ); + +container_numa_remove (device->handle); + } + +container_numa_detach_data (device->handle); pc = (struct acpi_container *)acpi_driver_data (device);if (pc)
@@ -198,6 +208,7 @@ container_device_add(struct acpi_deviceif (acpi_bus_add (device, pdev, handle,ACPI_BUS_TYPE_DEVICE )) {return_VALUE (-ENODEV ); } +container_numa_add ((*device)->handle); result =acpi_bus_scan (*device);
include/acpi/container.h renamed from include/acpi/container.h~container_for_numa +14 -1
@@ -2,12 +2,25 @@#define __ACPI_CONTAINER_H#include <linux/kernel.h> -struct acpi_container {acpi_handle handle;unsigned long sun;int state; }; +#ifdef CONFIG_ACPI_NUMA +#include <acpi/numa.h> +#define container_numa_init (handle) acpi_numa_node_init(handle) +#define container_numa_add (handle) acpi_numa_node_add(handle) +#define container_numa_remove (handle) acpi_numa_node_remove(handle) +#define container_numa_detach_data (handle) acpi_numa_node_data_detach(handle) +#define is_numa_node (handle) is_numa_node_device(acpi_handle handle) +#else +#define container_numa_init (handle) +#define container_numa_add (handle) +#define container_numa_remove (handle) +#define container_numa_detach_data (handle) +#define is_numa_node (handle) (0) +#endif #endif /* __ACPI_CONTAINER_H */
_
Re: [PATCH][4/4] Add NUMA node handling to the container driver
Quoted 13 lines · Keiichiro Tokunaga
Name: container_for_numa.patch
Status: Tested on 2.6.9-rc2Signed-off-by Keiichiro Tokunaga <[email protected]>Description:
Add NUMA node handling to the container driver.Thanks,
Keiichiro Tokunaga
---
drivers/acpi/container.c container_device_add(struct acpi_device · line 213
Quoted 6 lines
drivers/acpi/container.c renamed from drivers/acpi/container.c~container_for_numa +1
-0@@ -198,6 +208,7 @@ container_device_add(struct acpi_deviceif (acpi_bus_add (device, pdev, handle,ACPI_BUS_TYPE_DEVICE )) {return_VALUE (-ENODEV ); } +container_numa_add ((*device)->handle);
Maybe that should be :
container_numa_add(phandle);
instead? Device is the child at this point.
--Mika
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
Re: [PATCH][4/4] Add NUMA node handling to the container driver
Quoted 20 lines
Quoted 10 lines · Keiichiro Tokunaga
Name: container_for_numa.patch
Status: Tested on 2.6.9-rc2Signed-off-by Keiichiro Tokunaga <[email protected]>Description:
Add NUMA node handling to the container driver.Thanks,
Keiichiro Tokunaga
---drivers/acpi/container.c container_device_add(struct acpi_device · line 213
Quoted 6 lines
drivers/acpi/container.c renamed from drivers/acpi/container.c~container_for_numa +1
-0@@ -198,6 +208,7 @@ container_device_add(struct acpi_deviceif (acpi_bus_add (device, pdev, handle,ACPI_BUS_TYPE_DEVICE )) {return_VALUE (-ENODEV ); } +container_numa_add ((*device)->handle);Maybe that should be :
Quoted 3 lines
container_numa_add(phandle);instead? Device is the child at this point.
Thanks for looking!
A container's handle needs to be passed to the function here. The (*device)->handle is the handle. So there is no problem. The phandle is just used for acpi_bus_add().
Thanks,
Keiichiro Tokunaga
Re: [PATCH][0/4] NUMA node handling support for ACPI container driver
In reply to Keiichiro TokunagaQuoted 18 lines · Keiichiro Tokunaga
Quoted 8 lines · Keshavamurthy Anil S
Changes from previous release:
1) Typo fix- ACPI004 to ACPI0004
2) Added depends on EXPERIMENTAL inKconfigfile---
Name:container_drv.patch
Status: Tested on 2.6.9-rc1Signed-off-by Anil S Keshavamurthy <[email protected]>Quoted 8 lines
Depends:
Version: applies on 2.6.9-rc1
Description:
This is the very early version on the Container driver which supports hotplug notifications on ACPI0004, PNP0A05 and PNP0A06 devices.
Changes from previous release:
1) Mergerd the typo fix patch which changes "ACPI004" to "ACPI0004"
---
Quoted 5 lines
I have made a patchset to add 'NUMA node handling support' to your patchset. If a container that is identical to NUMA node is hotplugged, this handles NUMA related stuffs. For instance, creating/deleting sysfs directories and files of node, data structures, and etc...
Great!!!
Quoted 5 lines
- numa_hp_base.patch
- numa_hp_ia64.patch
- acpi_numa_hp.patch
- container_for_numa.patch
I will take a look at all of the above patches and will get back to you soon.
Quoted 2 lines
Status: Tested on 2.6.9-rc2 including your patchset posted earlier.
Sounds good.
thanks,
Anil Keshavamurthy
Re: PATCH-ACPI based CPU hotplug[6/6]-ACPI Container driver
In reply to Keshavamurthy Anil SQuoted 3 lines · Keshavamurthy Anil S
Changes from previous release:
1) Typo fix- ACPI004 to ACPI0004
2) Added depends on EXPERIMENTAL inKconfigfile
Refreshed this patch and added printk for ACPI_NOTIFY_BUS_CHECK
and for ACPI_NOTIFY_DEVICE_CHECK as no major issues were identified with this patch.
---
Name:container_drv.patch
Status: Tested on 2.6.9-rc1
Depends:
Version: applies on 2.6.9-rc1
Description:
This is the very early version on the Container driver which supports hotplug notifications on ACPI0004, PNP0A05 and PNP0A06 devices.
Changes from previous release:
1) Mergerd the typo fix patch which changes "ACPI004" to "ACPI0004"
---
linux-2.6.9-rc2-askeshav/drivers/acpi/Kconfig | 10 linux-2.6.9-rc2-askeshav/drivers/acpi/Makefile | 1 linux-2.6.9-rc2-askeshav/drivers/acpi/container.c | 344 ++++++++++++++++++++++ linux-2.6.9-rc2-askeshav/include/acpi/container.h | 13 4 files changed, 367 insertions(+), 1 deletion(-)
drivers/acpi/Kconfig renamed from drivers/acpi/Kconfig~container_drv +9 -1
@@ -133,6 +133,7 @@ config ACPI_HOTPLUG_CPU bool "Processor Hotplug (EXPERIMENTAL)" depends on ACPI_PROCESSOR && HOTPLUG_CPU && EXPERIMENTAL depends on !IA64_SGI_SN + select ACPI_CONTAINER default n ---help--- Select this option if your platform support physical CPU hotplug.
@@ -278,5 +279,12 @@ config X86_PM_TIMER kernel logs, and/or you are using this on a notebook which does not yet have an HPET, you should say "Y" here. -endmenu +config ACPI_CONTAINER + tristate "ACPI0004,PNP0A05 and PNP0A06 Container Driver (EXPERIMENTAL)" + depends on ACPI && EXPERIMENTAL + default (ACPI_HOTPLUG_MEMORY || ACPI_HOTPLUG_CPU || ACPI_HOTPLUG_IO) + ---help--- + This is the ACPI generic container driver which supports + ACPI0004, PNP0A05 and PNP0A06 devices +endmenu
drivers/acpi/Makefile renamed from drivers/acpi/Makefile~container_drv +1 -0
@@ -41,6 +41,7 @@ obj-$(CONFIG_ACPI_FAN) += fan.o obj-$(CONFIG_ACPI_PCI) += pci_root.o pci_link.o pci_irq.o pci_bind.o obj-$(CONFIG_ACPI_POWER) += power.o obj-$(CONFIG_ACPI_PROCESSOR) += processor.o +obj-$(CONFIG_ACPI_CONTAINER) += container.o obj-$(CONFIG_ACPI_THERMAL) += thermal.o obj-$(CONFIG_ACPI_SYSTEM) += system.o event.o obj-$(CONFIG_ACPI_DEBUG) += debug.o
include/acpi/container.h new file +13 -0
@@ -0,0 +1,13 @@ +#ifndef __ACPI_CONTAINER_H +#define __ACPI_CONTAINER_H + +#include <linux/kernel.h> + +struct acpi_container { +acpi_handle handle; +unsigned long sun; +int state; +}; + +#endif /* __ACPI_CONTAINER_H */ +
drivers/acpi/container.c new file +344 -0
344 lines not on this page · raw message
_