On Wednesday, November 20, 2013 02:11:34 PM Al Stone wrote: > On 11/17/2013 02:56 PM, Rafael J. Wysocki wrote: > > On Saturday, November 09, 2013 06:36:12 PM al.stone@xxxxxxxxxx wrote: > >> From: Al Stone <ahs3@xxxxxxxxxx> > >> > >> Remove the saving and restoring of bus master reload registers in > >> suspend/resume when in reduces HW mode; according to the spec, no > >> such registers should exist > >> > >> Signed-off-by: Al Stone <al.stone@xxxxxxxxxx> > >> --- > >> drivers/acpi/processor_idle.c | 8 +++++++- > >> include/acpi/acpixf.h | 6 ++++++ > >> 2 files changed, 13 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c > >> index 35c8f2b..28079a6 100644 > >> --- a/drivers/acpi/processor_idle.c > >> +++ b/drivers/acpi/processor_idle.c > >> @@ -210,6 +210,7 @@ static void lapic_timer_state_broadcast(struct acpi_processor *pr, > >> #endif > >> > >> #ifdef CONFIG_PM_SLEEP > >> +#if (!ACPI_REDUCED_HARDWARE) > > > > Why don't you use #ifndef CONFIG_ACPI_REDUCED_HARDWARE here? > > > > And I believe we don't need acpi_processor_syscore_ops in that case at all? > > > > So why don't you put the whole section under > > > > #if (IS_ENABLED(CONFIG_PM_SLEEP) && !IS_ENABLED(CONFIG_ACPI_REDUCED_HARDWARE)) ? > > My original thinking was that ACPI_REDUCED_HARDWARE is the flag > being used in the ACPICA code. On re-thinking it (and I'll use > your suggestion, if you don't mind), is it fair to say that there > is essentially a policy of keeping the Linux acpi driver and the > ACPICA code as separate as possible? We generally avoid mixing the code bases so that ACPICA upstream can make changes without worrying (too much) about breaking Linux inadvertently. In any case it is better to use Linux' symbols rather than ACPICA's symbols wherever possible. Thanks! -- I speak only for myself. Rafael J. Wysocki, 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
