Re: [PATCH 13/21] x86, acpi: Try to find SRAT in firmware earlier.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/24/2013 04:49 AM, Tejun Heo wrote:
On Fri, Jul 19, 2013 at 03:59:26PM +0800, Tang Chen wrote:
......
+	for (pos = 0;
+	     pos<  acpi_gbl_root_table_list.current_table_count;
+	     pos++) {
+		if (!ACPI_COMPARE_NAME
+		    (&(acpi_gbl_root_table_list.tables[pos].signature),
+		    signature))

Hohumm... creative formatting.  Can't you just cache the tables
pointer in a local variable with short name and avoid the creativity?

OK, followed.


+			continue;
+
+		memcpy(out_desc,&acpi_gbl_root_table_list.tables[pos],
+		       sizeof(struct acpi_table_desc));
+
+		return_ACPI_STATUS(AE_OK);
+	}
+
+	return_ACPI_STATUS(AE_NOT_FOUND);

Also, if we already know that SRAT is what we want, I wonder whether
it'd be simpler to store the location of SRAT somewhere instead of
trying to be generic with the early processing.

Do you mean get the SRAT's address without touching any ACPI global
variables, such as acpi_gbl_root_table_list ?

The physical addresses of all tables is stored in RSDT (Root System
Description Table), which is the root table. We need to parse RSDT
to get SRAT address.

Using acpi_gbl_root_table_list is very convenient. The initialization
of acpi_gbl_root_table_list is using acpi_os_map_memory(), so it can be
done before init_mem_mapping() and relocate_initrd().

With acpi_gbl_root_table_list initialized, we can iterate it and find
SRAT easily. Otherwise, we have to do the same procedure to parse RSDT,
and find SRAT, which I don't think could be any simpler. I think reuse
the existing acpi_gbl_root_table_list code is better.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux