Re: [PATCH v3 09/17] ARM64 / ACPI: Parse MADT for SMP initialization

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

 



Hi Jon,

On 2014年09月09日 12:23, Jon Masters wrote:
> On 09/01/2014 10:57 AM, Hanjun Guo wrote:
>> MADT contains the information for MPIDR which is essential for
>> SMP initialization, parse the GIC cpu interface structures to
>> get the MPIDR value and map it to cpu_logical_map(), and add
>> enabled cpu with valid MPIDR into cpu_possible_map.
>>
>> ACPI 5.1 only has two explicit methods to boot up SMP, PSCI and
>> Parking protocol, but the Parking protocol is only specified for
>> ARMv7 now, so make PSCI as the only way for the SMP boot protocol
>> before some updates for the ACPI spec or the Parking protocol spec.
>> +	/* CPU 0 was already initialized */
>> +	if (cpu) {
>> +		if (cpu_ops[cpu]->cpu_init(NULL, cpu))
>> +			return -EOPNOTSUPP;
>> +
>> +		/* map the logical cpu id to cpu MPIDR */
>> +		cpu_logical_map(cpu) = mpidr;
> I'm not sure it's worth noting in a comment or just in the dialogue that
> none of these MPIDR values is literally the value in the MPIDR. Linux
> doesn't store that anyway (even in the cpu_logical_map), since it is
> pre-filtered against MPIDR_HWID_BITMASK to remove the non-affinity level
> bits. And since the ACPI5.1 specification requires that non-affinity
> bits be zero everything works. But it relies upon this assumption so it
> might be worth explicitly masking out the bits when making the call into:
>
>        acpi_map_gic_cpu_interface(processor->arm_mpidr,
>                processor->flags & ACPI_MADT_ENABLED);
>
> During the parsing of the processor object's MPIDR value.

Yes, I agree with you. When I tested this patch set on our
ARM64 platform, I found this problem too. some firmware
will just present the real MPIDR value to OS which some reserved
bit set to 1, and it will lead to some logic problem in this patch.
(actually firmware didn't obey with ACPI spec)

I had updated the patch with:

+	acpi_map_gic_cpu_interface(processor->arm_mpidr & MPIDR_HWID_BITMASK,
+		processor->flags & ACPI_MADT_ENABLED);

and then the problem was gone :)

Thanks
Hanjun


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




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux