: ACPI: Rename ACPI processor device bus ID

PATCH RESEND In review yakui_zhao 3 participants 6 messages May 31, 2009 – Jun 8, 2009 ACPI

lore

Share & tools

lore

yakui_zhao

author

2009-05-31 02:30 UTC #0 lore raw

PATCH RESEND 1/1 : ACPI: Rename ACPI processor device bus ID

From: Zhao Yakui <[email protected]

On some boxes several processors use the same processor bus id. But they are located in different scope. For example:

	\_SB.SCK0.CPU0
	\_SB.SCK1.CPU0
	As they use the same bus id, it can't be registered when

registering proc I/F. It causes that the ACPI processor driver can't be bound with the processor device.

Rename the processor device bus id. And the new bus id will be generated as the following format:
CPU+ CPU ID

For example: If the cpu ID is 5, then the bus ID will be "CPU5".
If the CPU ID is 10, then the bus ID will be "CPUA".

Signed-off-by Zhao Yakui <[email protected]>

---
 drivers/acpi/processor_core.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

drivers/acpi/processor_core.c +10 -1

Index: linux-2.6/drivers/acpi/processor_core.c
===================================================================
@@ -649,7 +649,16 @@
 			return -ENODEV;
 		}
 	}
-
+	/*
+	 * On some boxes several processors use the same processor bus id.
+	 * But they are located in different scope. For example:
+	 * \_SB.SCK0.CPU0
+	 * \_SB.SCK1.CPU0
+	 * Rename the processor device bus id. And the new bus id will be
+	 * generated as the following format:
+	 * CPU+CPU ID.
+	 */
+	sprintf(acpi_device_bid(device), "CPU%X", pr->id);
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id,
 			  pr->acpi_id));

Thomas Renninger

2009-06-02 13:19 UTC #1 lore raw

drivers/acpi/processor_core.c line 661

Quoted 10 lines · On Sunday 31 May 2009 04:31:51 yakui_zhao wrote:

drivers/acpi/processor_core.c +10 -0

+	/*
+	 * On some boxes several processors use the same processor bus id.
+	 * But they are located in different scope. For example:
+	 * \_SB.SCK0.CPU0
+	 * \_SB.SCK1.CPU0
+	 * Rename the processor device bus id. And the new bus id will be
+	 * generated as the following format:
+	 * CPU+CPU ID.
+	 */
+	sprintf(acpi_device_bid(device), "CPU%X", pr->id);

Hm, there were several attempts to get rid of acpi_device_bid and friends.
Especially here, sprintfing into something function like looks really wrong.
Len, do you agree that not introducing new ones and at some point of time replacing:
acpi_device_bid(device)
with
device->pnp.bus_id
is the way to go?

Thanks,

Thomas

Quoted 7 lines

drivers/acpi/processor_core.c +0 -1
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id,
 			  pr->acpi_id));
 
 
 
--
To unsubscribe from this list: send the line "unsubscribe linux-

acpi" in

Quoted 3 lines

the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

yakui_zhao

author

2009-06-03 02:32 UTC #2 lore raw

Quoted 14 lines · Thomas Renninger

drivers/acpi/processor_core.c line 661
Quoted 10 lines · On Sunday 31 May 2009 04:31:51 yakui_zhao wrote:
drivers/acpi/processor_core.c +10 -0
+	/*
+	 * On some boxes several processors use the same processor bus id.
+	 * But they are located in different scope. For example:
+	 * \_SB.SCK0.CPU0
+	 * \_SB.SCK1.CPU0
+	 * Rename the processor device bus id. And the new bus id will be
+	 * generated as the following format:
+	 * CPU+CPU ID.
+	 */
+	sprintf(acpi_device_bid(device), "CPU%X", pr->id);
Hm, there were several attempts to get rid of acpi_device_bid and friends.

Quoted 8 lines

Especially here, sprintfing into something function like looks really wrong.
Len, do you agree that not introducing new ones and at some point of time replacing:
acpi_device_bid(device)
with
device->pnp.bus_id
is the way to go?

The acpi_device_bid is not a function. It is equal to the device->pnp.bus_id for the ACPI device.
#define acpi_device_bid(d) ((d)->pnp.bus_id)

Thanks.

Quoted 5 lines

Thanks,
Thomas

Quoted 13 lines

Quoted 7 lines
drivers/acpi/processor_core.c +0 -1
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id,
 			  pr->acpi_id));
 
 
 
--
To unsubscribe from this list: send the line "unsubscribe linux-
acpi" in
Quoted 3 lines
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Thomas Renninger

2009-06-03 09:14 UTC #3 lore raw

Quoted 23 lines · On Wednesday 03 June 2009 04:34:06 yakui_zhao wrote:

Quoted 14 lines · Thomas Renninger
drivers/acpi/processor_core.c line 661
Quoted 10 lines · On Sunday 31 May 2009 04:31:51 yakui_zhao wrote:
drivers/acpi/processor_core.c +10 -0
+	/*
+	 * On some boxes several processors use the same processor bus id.
+	 * But they are located in different scope. For example:
+	 * \_SB.SCK0.CPU0
+	 * \_SB.SCK1.CPU0
+	 * Rename the processor device bus id. And the new bus id will be
+	 * generated as the following format:
+	 * CPU+CPU ID.
+	 */
+	sprintf(acpi_device_bid(device), "CPU%X", pr->id);
Hm, there were several attempts to get rid of acpi_device_bid and friends.
Quoted 8 lines
Especially here, sprintfing into something function like looks really wrong.
Len, do you agree that not introducing new ones and at some point of time replacing:
acpi_device_bid(device)
with
device->pnp.bus_id
is the way to go?

Quoted 3 lines

The acpi_device_bid is not a function. It is equal to the device->pnp.bus_id for the ACPI device.
#define acpi_device_bid(d) ((d)->pnp.bus_id)

this #define should vanish sooner or later.
Several people suggested to get rid of these already. Why don't you use:
sprintf(device->pnp.bus_id, "CPU%X", pr->id); Unfortunately these constructs are rather common in drivers/acpi, thus I ask whether these should be avoided or not.

Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Len Brown

reviewer

2009-06-06 01:51 UTC #4 lore raw

In reply to yakui_zhao

We've promised to delete /proc/acpi instead of enhance it, so i'd rather see a patch that ignores errors from procfs and registers the driver even when procfs fails.

thanks,
Len Brown, Intel Open Source Technology Center

Quoted 51 lines · yakui_zhao

From: Zhao Yakui <[email protected]
On some boxes several processors use the same processor bus id. But they are located in different scope. For example:
	\_SB.SCK0.CPU0
	\_SB.SCK1.CPU0
	As they use the same bus id, it can't be registered when
registering proc I/F. It causes that the ACPI processor driver can't be bound with the processor device.
Rename the processor device bus id. And the new bus id will be generated as the following format:
CPU+ CPU ID
For example: If the cpu ID is 5, then the bus ID will be "CPU5".
If the CPU ID is 10, then the bus ID will be "CPUA".
Signed-off-by Zhao Yakui <[email protected]>
---
 drivers/acpi/processor_core.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/acpi/processor_core.c
===================================================================
drivers/acpi/processor_core.c +10 -2
@@ -649,7 +649,16 @@
 			return -ENODEV;
 		}
 	}
-
+	/*
+	 * On some boxes several processors use the same processor bus id.
+	 * But they are located in different scope. For example:
+	 * \_SB.SCK0.CPU0
+	 * \_SB.SCK1.CPU0
+	 * Rename the processor device bus id. And the new bus id will be
+	 * generated as the following format:
+	 * CPU+CPU ID.
+	 */
+	sprintf(acpi_device_bid(device), "CPU%X", pr->id);
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id,
 			  pr->acpi_id));
 
 
 
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

yakui_zhao

author

2009-06-08 08:01 UTC #5 lore raw

Quoted 3 lines · Len Brown

We've promised to delete /proc/acpi instead of enhance it, so i'd rather see a patch that ignores errors from procfs and registers the driver even when procfs fails.

The issue can also be fixed by deleting the ACPI processor proc I/F. I will send a patch that depreciated the ACPI processor proc I/F. When the CONFIG_ACPI_PROCFS is unset in kernel configuration, the processor proc I/F won't be created.
thanks.

Quoted 56 lines

thanks,
Len Brown, Intel Open Source Technology Center
Quoted 51 lines · yakui_zhao
From: Zhao Yakui <[email protected]
On some boxes several processors use the same processor bus id. But they are located in different scope. For example:
	\_SB.SCK0.CPU0
	\_SB.SCK1.CPU0
	As they use the same bus id, it can't be registered when
registering proc I/F. It causes that the ACPI processor driver can't be bound with the processor device.
Rename the processor device bus id. And the new bus id will be generated as the following format:
CPU+ CPU ID
For example: If the cpu ID is 5, then the bus ID will be "CPU5".
If the CPU ID is 10, then the bus ID will be "CPUA".
Signed-off-by Zhao Yakui <[email protected]>
---
 drivers/acpi/processor_core.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/acpi/processor_core.c
===================================================================
drivers/acpi/processor_core.c +10 -2
@@ -649,7 +649,16 @@
 			return -ENODEV;
 		}
 	}
-
+	/*
+	 * On some boxes several processors use the same processor bus id.
+	 * But they are located in different scope. For example:
+	 * \_SB.SCK0.CPU0
+	 * \_SB.SCK1.CPU0
+	 * Rename the processor device bus id. And the new bus id will be
+	 * generated as the following format:
+	 * CPU+CPU ID.
+	 */
+	sprintf(acpi_device_bid(device), "CPU%X", pr->id);
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id,
 			  pr->acpi_id));
 
 
 
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html