All of lore.kernel.org
 help / color / mirror / Atom feed
From: Myron Stowe <myron.stowe@hp.com>
To: Zhao Yakui <yakui.zhao@intel.com>
Cc: "lenb@kernel.org" <lenb@kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Alexey Starikovskiy <aystarik@gmail.com>
Subject: Re: [PATCH v2 2/3] ACPI: Behave uniquely based on processor declaration definition type
Date: Sun, 02 Nov 2008 17:10:36 -0700	[thread overview]
Message-ID: <1225671037.8772.30.camel@localhost> (raw)
In-Reply-To: <1225415958.3993.10.camel@yakui_zhao.sh.intel.com>

On Fri, 2008-10-31 at 09:19 +0800, Zhao Yakui wrote:
> On Fri, 2008-10-31 at 06:13 +0800, Myron Stowe wrote:
> > Associating a Local SAPIC with a processor object is dependent upon the
> > processor object's definition type.  CPUs declared as "Processor" should
> > use the Local SAPIC's 'processor_id', and CPUs declared as "Device"
> > should use the 'uid'.  Note that for "Processor" declarations, even if a
> > '_UID' child object exists, it has no bearing with respect to mapping
> > Local SAPICs (see section 5.2.11.13 - Local SAPIC Structure; "Advanced
> > Configuration and Power Interface Specification", Revision 3.0b).
> > 
> > This patch changes the lsapic mapping logic to rely on the distinction of
> > how the processor object was declared - the mapping can't just try both
> > types of matches irregardless of declaration type and rely on one failing
> > as is currently being done.
> > 
> > Signed-off-by: Myron Stowe <myron.stowe@hp.com>
> > Cc: Alexey Starikovskiy <aystarik@gmail.com>
> > Cc: Zhao Yakui <yakui.zhao@intel.com>
> > ---
> > 
> >  drivers/acpi/processor_core.c |   75 +++++++++++++++++++++++------------------
> >  1 files changed, 42 insertions(+), 33 deletions(-)
> > 
> > diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
> > index 0c670dd..35d33e8 100644
> > --- a/drivers/acpi/processor_core.c
> > +++ b/drivers/acpi/processor_core.c
> > @@ -410,7 +410,7 @@ static int acpi_processor_remove_fs(struct acpi_device *device)
> >  /* Use the acpiid in MADT to map cpus in case of SMP */
> >  
> >  #ifndef CONFIG_SMP
> > -static int get_cpu_id(acpi_handle handle, u32 acpi_id) {return -1;}
> > +static int get_cpu_id(acpi_handle handle, int type, u32 acpi_id) { return -1; }
> >  #else
> >  
> >  static struct acpi_table_madt *madt;
> > @@ -429,27 +429,35 @@ static int map_lapic_id(struct acpi_subtable_header *entry,
> >  }
> >  
> >  static int map_lsapic_id(struct acpi_subtable_header *entry,
> > -		  u32 acpi_id, int *apic_id)
> > +		int device_declaration, u32 acpi_id, int *apic_id)
> >  {
> >  	struct acpi_madt_local_sapic *lsapic =
> >  		(struct acpi_madt_local_sapic *)entry;
> > +	u32 tmp = (lsapic->id << 8) | lsapic->eid;
> > +
> >  	/* Only check enabled APICs*/
> > -	if (lsapic->lapic_flags & ACPI_MADT_ENABLED) {
> > -		/* First check against id */
> > -		if (lsapic->processor_id == acpi_id) {
> > -			*apic_id = (lsapic->id << 8) | lsapic->eid;
> > -			return 1;
> > -		/* Check against optional uid */
> > -		} else if (entry->length >= 16 &&
> > -			lsapic->uid == acpi_id) {
> > -			*apic_id = lsapic->uid;
> > -			return 1;
> > -		}
> > -	}
> > +	if (!(lsapic->lapic_flags & ACPI_MADT_ENABLED))
> > +		return 0;
> > +
> > +	/* Device statement declaration type */
> > +	if (device_declaration) {
> > +		if (entry->length < 16)
> > +			printk(KERN_ERR PREFIX
> > +			    "Invalid LSAPIC with Device type processor (SAPIC ID %#x)\n",
> > +			    tmp);
> > +		else if (lsapic->uid == acpi_id)
> > +			goto found;
> > +	/* Processor statement declaration type */
> > +	} else if (lsapic->processor_id == acpi_id)
> > +		goto found;
> > +
> >  	return 0;
> > +found:
> > +	*apic_id = tmp;
> > +	return 1;
> >  }
> >  
> > -static int map_madt_entry(u32 acpi_id)
> > +static int map_madt_entry(int type, u32 acpi_id)
> >  {
> >  	unsigned long madt_end, entry;
> >  	int apic_id = -1;
> > @@ -470,7 +478,7 @@ static int map_madt_entry(u32 acpi_id)
> >  			if (map_lapic_id(header, acpi_id, &apic_id))
> >  				break;
> >  		} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
> > -			if (map_lsapic_id(header, acpi_id, &apic_id))
> > +			if (map_lsapic_id(header, type, acpi_id, &apic_id))
> >  				break;
> >  		}
> >  		entry += header->length;
> > @@ -478,7 +486,7 @@ static int map_madt_entry(u32 acpi_id)
> >  	return apic_id;
> >  }
> >  
> > -static int map_mat_entry(acpi_handle handle, u32 acpi_id)
> > +static int map_mat_entry(acpi_handle handle, int type, u32 acpi_id)
> >  {
> >  	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> >  	union acpi_object *obj;
> > @@ -501,7 +509,7 @@ static int map_mat_entry(acpi_handle handle, u32 acpi_id)
> >  	if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) {
> >  		map_lapic_id(header, acpi_id, &apic_id);
> >  	} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
> > -		map_lsapic_id(header, acpi_id, &apic_id);
> > +		map_lsapic_id(header, type, acpi_id, &apic_id);
> >  	}
> >  
> >  exit:
> > @@ -510,14 +518,14 @@ exit:
> >  	return apic_id;
> >  }
> >  
> > -static int get_cpu_id(acpi_handle handle, u32 acpi_id)
> > +static int get_cpu_id(acpi_handle handle, int type, u32 acpi_id)
> >  {
> >  	int i;
> >  	int apic_id = -1;
> >  
> > -	apic_id = map_mat_entry(handle, acpi_id);
> > +	apic_id = map_mat_entry(handle, type, acpi_id);
> >  	if (apic_id == -1)
> > -		apic_id = map_madt_entry(acpi_id);
> > +		apic_id = map_madt_entry(type, acpi_id);
> >  	if (apic_id == -1)
> >  		return apic_id;
> >  
> > @@ -533,15 +541,16 @@ static int get_cpu_id(acpi_handle handle, u32 acpi_id)
> >                                   Driver Interface
> >     -------------------------------------------------------------------------- */
> >  
> > -static int acpi_processor_get_info(struct acpi_processor *pr, unsigned has_uid)
> > +static int acpi_processor_get_info(struct acpi_device *device)
> >  {
> >  	acpi_status status = 0;
> >  	union acpi_object object = { 0 };
> >  	struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
> > -	int cpu_index;
> > +	struct acpi_processor *pr;
> > +	int cpu_index, device_declaration = 0;
> >  	static int cpu0_initialized;
> >  
> > -
> > +	pr = acpi_driver_data(device);
> >  	if (!pr)
> >  		return -EINVAL;
> >  
> > @@ -562,8 +571,11 @@ static int acpi_processor_get_info(struct acpi_processor *pr, unsigned has_uid)
> >  		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> >  				  "No bus mastering arbitration control\n"));
> >  
> > -	/* Check if it is a Device with HID and UID */
> > -	if (has_uid) {
> > +	if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_HID)) {
> > +		/*
> > +		 * Declared with "Device" statement; match _UID.
> > +		 * Note that we don't handle string _UIDs yet.
> Looks very good. 
> Can you add the check whether the device.flags.unique_id exists before
> evaluating the _UID object? 
> If not exist, it indicates that the processor definition is incorrect.

The additional check would create a relationship with
'device.flags.unique_id' which seems redundant and would introduce
unnecessary complexity going forward.  While such an additional check
would possibly short circuit the call to 'acpi_evaluate_integer()' -
when FW is in error and a _UID child object does not exist; a case that
is already caught - this code is not in a performance path and thus
seems to yield no benefit.

Was there some other aspect that you were thinking of?

Myron

> Thanks.
> > +		 */
> >  		unsigned long long value;
> >  		status = acpi_evaluate_integer(pr->handle, METHOD_NAME__UID,
> >  						NULL, &value);
> > @@ -571,13 +583,10 @@ static int acpi_processor_get_info(struct acpi_processor *pr, unsigned has_uid)
> >  			printk(KERN_ERR PREFIX "Evaluating processor _UID\n");
> >  			return -ENODEV;
> >  		}
> > +		device_declaration = 1;
> >  		pr->acpi_id = value;
> >  	} else {
> > -		/*
> > -		* Evalute the processor object.  Note that it is common on SMP to
> > -		* have the first (boot) processor with a valid PBLK address while
> > -		* all others have a NULL address.
> > -		*/
> > +		/* Declared with "Processor" statement; match ProcessorID */
> >  		status = acpi_evaluate_object(pr->handle, NULL, NULL, &buffer);
> >  		if (ACPI_FAILURE(status)) {
> >  			printk(KERN_ERR PREFIX "Evaluating processor object\n");
> > @@ -590,7 +599,7 @@ static int acpi_processor_get_info(struct acpi_processor *pr, unsigned has_uid)
> >  		*/
> >  		pr->acpi_id = object.processor.proc_id;
> >  	}
> > -	cpu_index = get_cpu_id(pr->handle, pr->acpi_id);
> > +	cpu_index = get_cpu_id(pr->handle, device_declaration, pr->acpi_id);
> >  
> >  	/* Handle UP system running SMP kernel, with no LAPIC in MADT */
> >  	if (!cpu0_initialized && (cpu_index == -1) &&
> > @@ -662,7 +671,7 @@ static int __cpuinit acpi_processor_start(struct acpi_device *device)
> >  
> >  	pr = acpi_driver_data(device);
> >  
> > -	result = acpi_processor_get_info(pr, device->flags.unique_id);
> > +	result = acpi_processor_get_info(device);
> >  	if (result) {
> >  		/* Processor is physically not present */
> >  		return 0;
> > 
> 
-- 
Myron Stowe                             HP Open Source & Linux Org


  reply	other threads:[~2008-11-03  0:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-30 22:13 [PATCH v2 0/3] ACPI: Fix for supporting > 256 processor declaration limit Myron Stowe
2008-10-30 22:13 ` [PATCH v2 1/3] ACPI: Disambiguate processor declaration type Myron Stowe
2008-10-30 22:13 ` [PATCH v2 2/3] ACPI: Behave uniquely based on processor declaration definition type Myron Stowe
2008-10-31  1:19   ` Zhao Yakui
2008-11-03  0:10     ` Myron Stowe [this message]
2008-11-03  1:15       ` Zhao Yakui
2008-11-03  2:42         ` Bjorn Helgaas
2008-11-03  2:51         ` Myron Stowe
2008-11-03  3:59           ` Zhao Yakui
2008-11-03 21:27             ` Bjorn Helgaas
2008-10-30 22:13 ` [PATCH v2 3/3] ACPI: 80 column adherence and spelling fix (no functional change) Myron Stowe

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=1225671037.8772.30.camel@localhost \
    --to=myron.stowe@hp.com \
    --cc=aystarik@gmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yakui.zhao@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 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.