public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
To: akpm@osdl.org
Cc: linux-kernel@vger.kernel.org, ashok.raj@intel.com,
	tony.luck@intel.com, paulus@samba.org, ak@suse.de
Subject: [patch] change the 'no_control' field to 'hotpluggable' in the struct cpu
Date: Fri, 10 Nov 2006 16:43:38 -0800	[thread overview]
Message-ID: <20061110164338.B25478@unix-os.sc.intel.com> (raw)
In-Reply-To: <20061107212332.A6418@unix-os.sc.intel.com>; from suresh.b.siddha@intel.com on Tue, Nov 07, 2006 at 09:23:32PM -0800

On Tue, Nov 07, 2006 at 09:23:32PM -0800, Siddha, Suresh B wrote:
> On Tue, Nov 07, 2006 at 08:35:04PM -0800, Andrew Morton wrote:
> > "Siddha, Suresh B" <suresh.b.siddha@intel.com> wrote:
> > 
> > > I wanted to add something like disable_cpu_hotplug
> > 
> > My point is, `enable_cpu_hotplug' is nicer
> 
> Yep. I got it and hence my "will clean this up" assurance :)
> 
> This is all coming from the `no_control' member in cpu structure and I will
> change that to something like `hotpluggable'. That will make the patch slightly
> big but def clean.

Andrew, Appended the cleanup patch which goes on top of your -mm tree.
Please apply. Thanks.
---

Change the 'no_control' field in the cpu struct to a more positive
and better term 'hotpluggable'. And change(/cleanup) the logic accordingly.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---

diff --git a/arch/i386/kernel/topology.c b/arch/i386/kernel/topology.c
index 844c08f..79cf608 100644
--- a/arch/i386/kernel/topology.c
+++ b/arch/i386/kernel/topology.c
@@ -44,8 +44,8 @@ int arch_register_cpu(int num)
 	 * Also certain PCI quirks require not to enable hotplug control
 	 * for all CPU's.
 	 */
-	if (!num || !enable_cpu_hotplug)
-		cpu_devices[num].cpu.no_control = 1;
+	if (num && enable_cpu_hotplug)
+		cpu_devices[num].cpu.hotpluggable = 1;
 
 	return register_cpu(&cpu_devices[num].cpu, num);
 }
diff --git a/arch/ia64/kernel/topology.c b/arch/ia64/kernel/topology.c
index 5629b45..687500d 100644
--- a/arch/ia64/kernel/topology.c
+++ b/arch/ia64/kernel/topology.c
@@ -31,11 +31,11 @@ int arch_register_cpu(int num)
 {
 #if defined (CONFIG_ACPI) && defined (CONFIG_HOTPLUG_CPU)
 	/*
-	 * If CPEI cannot be re-targetted, and this is
-	 * CPEI target, then dont create the control file
+	 * If CPEI can be re-targetted or if this is not
+	 * CPEI target, then it is hotpluggable
 	 */
-	if (!can_cpei_retarget() && is_cpu_cpei_target(num))
-		sysfs_cpus[num].cpu.no_control = 1;
+	if (can_cpei_retarget() || !is_cpu_cpei_target(num))
+		sysfs_cpus[num].cpu.hotpluggable = 1;
 	map_cpu_to_node(num, node_cpuid[num].nid);
 #endif
 
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index d45a168..bf65a15 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -240,7 +240,7 @@ static void unregister_cpu_online(unsign
 	struct cpu *c = &per_cpu(cpu_devices, cpu);
 	struct sys_device *s = &c->sysdev;
 
-	BUG_ON(c->no_control);
+	BUG_ON(!c->hotpluggable);
 
 #ifndef CONFIG_PPC_ISERIES
 	if (cpu_has_feature(CPU_FTR_SMT))
@@ -360,10 +360,10 @@ static int __init topology_init(void)
 		 * CPU.  For instance, the boot cpu might never be valid
 		 * for hotplugging.
 		 */
-		if (!ppc_md.cpu_die)
-			c->no_control = 1;
+		if (ppc_md.cpu_die)
+			c->hotpluggable = 1;
 
-		if (cpu_online(cpu) || (c->no_control == 0)) {
+		if (cpu_online(cpu) || c->hotpluggable) {
 			register_cpu(c, cpu);
 
 			sysdev_create_file(&c->sysdev, &attr_physical_id);
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 4bef76a..d00c67c 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -103,8 +103,8 @@ #endif
 
 /*
  * register_cpu - Setup a driverfs device for a CPU.
- * @cpu - Callers can set the cpu->no_control field to 1, to indicate not to
- *		  generate a control file in sysfs for this CPU.
+ * @cpu - cpu->hotpluggable field set to 1 will generate a control file in
+ *	  sysfs for this CPU.
  * @num - CPU number to use when creating the device.
  *
  * Initialize and register the CPU device.
@@ -118,7 +118,7 @@ int __devinit register_cpu(struct cpu *c
 
 	error = sysdev_register(&cpu->sysdev);
 
-	if (!error && !cpu->no_control)
+	if (!error && cpu->hotpluggable)
 		register_cpu_control(cpu);
 	if (!error)
 		cpu_sys_devices[num] = &cpu->sysdev;
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 3fef7d6..a1fd791 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -27,7 +27,7 @@ #include <asm/semaphore.h>
 
 struct cpu {
 	int node_id;		/* The node which contains the CPU */
-	int no_control;		/* Should the sysfs control file be created? */
+	int hotpluggable;	/* creates sysfs control file if hotpluggable */
 	struct sys_device sysdev;
 };
 

  reply	other threads:[~2006-11-11  1:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-08  1:33 [patch 0/4] i386, x86_64: fix the irqbalance quirk for E7520/E7320/E7525 Siddha, Suresh B
2006-11-08  1:36 ` [patch 1/4] add write_pci_config_byte() to direct PCI access routines Siddha, Suresh B
2006-11-08  1:40   ` [patch 2/4] introduce the mechanism of disabling cpu hotplug control Siddha, Suresh B
2006-11-08  1:43     ` [patch 3/4] x86_64: add genapic_force Siddha, Suresh B
2006-11-08  1:46       ` [patch 4/4] fix the irqbalance quirk for E7320/E7520/E7525 Siddha, Suresh B
2006-11-08  3:54     ` [patch 2/4] introduce the mechanism of disabling cpu hotplug control Andrew Morton
2006-11-08  4:01       ` Siddha, Suresh B
2006-11-08  4:35         ` Andrew Morton
2006-11-08  5:23           ` Siddha, Suresh B
2006-11-11  0:43             ` Siddha, Suresh B [this message]
2006-11-08  4:07 ` [patch 0/4] i386, x86_64: fix the irqbalance quirk for E7520/E7320/E7525 Andrew Morton
2006-11-08  4:06   ` Siddha, Suresh B

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061110164338.B25478@unix-os.sc.intel.com \
    --to=suresh.b.siddha@intel.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=ashok.raj@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox