| Message ID | 1243737111.3634.168.camel@localhost.localdomain (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Headers | show |
On Sunday 31 May 2009 04:31:51 yakui_zhao wrote: > + /* > + * 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 > 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 majordomo@vger.kernel.org > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2009-06-02 at 21:19 +0800, Thomas Renninger wrote: > On Sunday 31 May 2009 04:31:51 yakui_zhao wrote: > > > + /* > > + * 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? 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. > > Thanks, > > Thomas > > > 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 majordomo@vger.kernel.org > > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 03 June 2009 04:34:06 yakui_zhao wrote: > On Tue, 2009-06-02 at 21:19 +0800, Thomas Renninger wrote: > > On Sunday 31 May 2009 04:31:51 yakui_zhao wrote: > > > > > + /* > > > + * 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? > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 On Sun, 31 May 2009, yakui_zhao wrote: > From: Zhao Yakui <yakui.zhao@intel.com > > 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 <yakui.zhao@intel.com> > --- > drivers/acpi/processor_core.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > Index: linux-2.6/drivers/acpi/processor_core.c > =================================================================== > --- linux-2.6.orig/drivers/acpi/processor_core.c 2009-05-27 08:38:44.000000000 +0800 > +++ linux-2.6/drivers/acpi/processor_core.c 2009-05-31 10:21:21.000000000 +0800 > @@ -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 majordomo@vger.kernel.org > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 2009-06-06 at 09:51 +0800, Len Brown wrote: > 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. > thanks, > Len Brown, Intel Open Source Technology Center > > On Sun, 31 May 2009, yakui_zhao wrote: > > > From: Zhao Yakui <yakui.zhao@intel.com > > > > 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 <yakui.zhao@intel.com> > > --- > > drivers/acpi/processor_core.c | 11 ++++++++++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > Index: linux-2.6/drivers/acpi/processor_core.c > > =================================================================== > > --- linux-2.6.orig/drivers/acpi/processor_core.c 2009-05-27 08:38:44.000000000 +0800 > > +++ linux-2.6/drivers/acpi/processor_core.c 2009-05-31 10:21:21.000000000 +0800 > > @@ -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 majordomo@vger.kernel.org > > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux-2.6/drivers/acpi/processor_core.c =================================================================== --- linux-2.6.orig/drivers/acpi/processor_core.c 2009-05-27 08:38:44.000000000 +0800 +++ linux-2.6/drivers/acpi/processor_core.c 2009-05-31 10:21:21.000000000 +0800 @@ -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));