> > Note also that an alternative for newer systems > > is to use the intel_idle driver, which always > > ignores BM_STS, relying Linux device drivers > > to register constraints explicitly via PM_QOS. > > > > https://bugzilla.kernel.org/show_bug.cgi?id=15886 > > Thanks. I don't fully understand why the check for this option > is in a different place than the register check in the earlier patch? Technically, it could have been. There are a comple of constraints in the layout of this code. The _CST flag is x86 (actually Intel) specific -- so the detection went into arch/x86/kernel/acpi/cstate.c However, the operation of the that flag is per C-state, not necessarily per system -- so we remember the flag in in a cx->bm_sts_skip flag and check it in the 'acpi generic' drivers/acpi/processor_idle.c But we can't test a per cx flag inside acpi_idle_bm_check() because it doesn't have access to the cx, so i put that test at the site of its only caller. In this 2nd patch... we added a 'generic' ACPI bootparam that applies to all C-states. So it overrides any per-cstate flag and it is static to the processor_idle.c file, so it seemed cleanest (to me) to push it down inside acpi_idle_bm_check() rather than in its only caller. > This needs to be also documented in Documentation/kernel-parameters.txt I thought about that and decided against it. While we do document some driver specific modparams in kernel-parameters.txt, I do not expect this one to be used that often -- mostly for diagnosis of BIOS bugs. I know of two machines that need it, and both of those machines have a BIOS update or a BIOS update in progress that make it unnecessary. thanks for caring. Len Brown, Intel Open Source Technology Center. -- 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
