On 01/16/2017 12:28 PM, Lorenzo Pieralisi wrote:
On Tue, Jan 10, 2017 at 11:17:51AM -0600, Jeremy Linton wrote: [...]+static int __init pmu_acpi_init(void) +{ + struct pmu_types *pmu, *safe_temp; + bool unused_madt_entries; + LIST_HEAD(pmus); + + if (acpi_disabled) + return 0; + + unused_madt_entries = arm_pmu_acpi_determine_cpu_types(&pmus);IIUC (and that's an if) unused_madt_entries is a "buffer" that you add to all platform devices you manage to create through midr matching to make sure there are enough resource entries when/if a cpu of the respective type is onlined. If that's the case unused_madt_entries can't be a bool.
Some where along in the patch churn, it transformed from a bool indicating there were extras to the count which triggered allocation at max cpu counts to just adding in the difference. So yes, its a bug if there is more than 1 offline CPU. I will resubmit it.
Second question I have is what happens if cpus that aren't online have an midr that differs from all the entries parsed at init time (ie those you created a platform device for), that's certainly a pesky corner case though.
Yes, right now if you have an entire class of cores offline at boot and they are later brought online, they won't get PMU entries because that requires creating another platform device, and the posted code can't handle that. I was ignoring it for this patch set because it fails gracefully and I didn't want to add even more churn.
-- 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
