On Sunday, September 16, 2012, Daniel Lezcano wrote: > On 09/07/2012 11:50 PM, Rafael J. Wysocki wrote: > > On Friday, September 07, 2012, Daniel Lezcano wrote: > >> The cpuidle core takes care of filling this field from drv->state_count. > > > > I'm not quite sure this is always valid. If dev has already been > > initialized and dev->state_count is different from 0, > > cpuidle_enable_device() doesn't actually change it. > > > > Have you considered all of the possible scenarios? > > Ok, there is the scenario where the ACPI supports _CST. > At runtime, ACPI may notify the OS a C-state changed for a specific cpu > and this is done through 'acpi_processor_cst_has_changed' followed by > 'acpi_processor_setup_cpuidle_cx'. > > So at the end, we could have different cpus with one cpu with less > C-states than the other, if I understood correctly ACPIspec30.pdf => > page 262 :) > > In conclusion, we should keep this variable filled from there and keep > this in mind in cpuidle.c in order to not break acpi in the future. > Maybe a comment in cpuidle.c would help ... especially with a single > C-state registration. Sure, adding a comment in there sounds like a good idea. Thanks, Rafael -- 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
