All of lore.kernel.org
 help / color / mirror / Atom feed
* [Resend] [PATCH]: ACPI: Rename ACPI processor device bus ID
@ 2009-05-31  2:31 yakui_zhao
  2009-06-02 13:19 ` Thomas Renninger
  2009-06-06  1:51 ` Len Brown
  0 siblings, 2 replies; 6+ messages in thread
From: yakui_zhao @ 2009-05-31  2:31 UTC (permalink / raw)
  To: lenb; +Cc: linux-acpi

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));
 



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Resend] [PATCH]: ACPI: Rename ACPI processor device bus ID
  2009-05-31  2:31 [Resend] [PATCH]: ACPI: Rename ACPI processor device bus ID yakui_zhao
@ 2009-06-02 13:19 ` Thomas Renninger
  2009-06-03  2:34   ` yakui_zhao
  2009-06-06  1:51 ` Len Brown
  1 sibling, 1 reply; 6+ messages in thread
From: Thomas Renninger @ 2009-06-02 13:19 UTC (permalink / raw)
  To: yakui_zhao; +Cc: lenb, linux-acpi

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
> 



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Resend] [PATCH]: ACPI: Rename ACPI processor device bus ID
  2009-06-02 13:19 ` Thomas Renninger
@ 2009-06-03  2:34   ` yakui_zhao
  2009-06-03  9:14     ` Thomas Renninger
  0 siblings, 1 reply; 6+ messages in thread
From: yakui_zhao @ 2009-06-03  2:34 UTC (permalink / raw)
  To: Thomas Renninger; +Cc: lenb, linux-acpi

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Resend] [PATCH]: ACPI: Rename ACPI processor device bus ID
  2009-06-03  2:34   ` yakui_zhao
@ 2009-06-03  9:14     ` Thomas Renninger
  0 siblings, 0 replies; 6+ messages in thread
From: Thomas Renninger @ 2009-06-03  9:14 UTC (permalink / raw)
  To: yakui_zhao; +Cc: lenb, linux-acpi

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Resend] [PATCH]: ACPI: Rename ACPI processor device bus ID
  2009-05-31  2:31 [Resend] [PATCH]: ACPI: Rename ACPI processor device bus ID yakui_zhao
  2009-06-02 13:19 ` Thomas Renninger
@ 2009-06-06  1:51 ` Len Brown
  2009-06-08  8:03   ` yakui_zhao
  1 sibling, 1 reply; 6+ messages in thread
From: Len Brown @ 2009-06-06  1:51 UTC (permalink / raw)
  To: yakui_zhao; +Cc: linux-acpi

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
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Resend] [PATCH]: ACPI: Rename ACPI processor device bus ID
  2009-06-06  1:51 ` Len Brown
@ 2009-06-08  8:03   ` yakui_zhao
  0 siblings, 0 replies; 6+ messages in thread
From: yakui_zhao @ 2009-06-08  8:03 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi

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
> > 


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-06-08  8:01 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-31  2:31 [Resend] [PATCH]: ACPI: Rename ACPI processor device bus ID yakui_zhao
2009-06-02 13:19 ` Thomas Renninger
2009-06-03  2:34   ` yakui_zhao
2009-06-03  9:14     ` Thomas Renninger
2009-06-06  1:51 ` Len Brown
2009-06-08  8:03   ` yakui_zhao

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.