linux-kernel - Re: [PATCH] x86: Bypass legacy PIC and PIT on ACPI hardware reduced platform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150304050858.GB5158@gmail.com>
Date:	Wed, 4 Mar 2015 06:08:58 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	"Li, Aubrey" <aubrey.li@...ux.intel.com>
Cc:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, arjan@...ux.intel.com,
	"Rafael J. Wysocki" <rjw@...ysocki.net>, Len.Brown@...el.com,
	x86@...nel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: Bypass legacy PIC and PIT on ACPI hardware reduced
 platform


* Li, Aubrey <aubrey.li@...ux.intel.com> wrote:

> On ACPI hardware reduced platform, the legacy PIC and PIT may not be
> initialized even though they may be present in silicon. Touching
> these legacy components causes unexpected result on system.
> 
> On Bay Trail-T(ASUS-T100) platform, touching these legacy components
> blocks platform hardware low idle power state(S0ix) during system suspend.
> So we should bypass them on ACPI hardware reduced platform.
> 
> Suggested-by: Arjan van de Ven <arjan@...ux.intel.com>
> Signed-off-by: Li Aubrey <aubrey.li@...ux.intel.com>
> Cc: Len Brown <len.brown@...el.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> ---
>  arch/x86/kernel/irqinit.c | 6 +++++-
>  arch/x86/kernel/time.c    | 3 ++-
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
> index 70e181e..9a64cc3 100644
> --- a/arch/x86/kernel/irqinit.c
> +++ b/arch/x86/kernel/irqinit.c
> @@ -75,7 +75,11 @@ void __init init_ISA_irqs(void)
>  #if defined(CONFIG_X86_64) || defined(CONFIG_X86_LOCAL_APIC)
>  	init_bsp_APIC();
>  #endif
> -	legacy_pic->init(0);
> +	if (acpi_gbl_reduced_hardware) {
> +		pr_info("Using NULL legacy PIC\n");
> +		legacy_pic = &null_legacy_pic;
> +	} else
> +		legacy_pic->init(0);
>  
>  	for (i = 0; i < nr_legacy_irqs(); i++)
>  		irq_set_chip_and_handler(i, chip, handle_level_irq);
> diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c
> index 25adc0e..5ba94fa 100644
> --- a/arch/x86/kernel/time.c
> +++ b/arch/x86/kernel/time.c
> @@ -14,6 +14,7 @@
>  #include <linux/i8253.h>
>  #include <linux/time.h>
>  #include <linux/export.h>
> +#include <linux/acpi.h>
>  
>  #include <asm/vsyscall.h>
>  #include <asm/x86_init.h>
> @@ -76,7 +77,7 @@ void __init setup_default_timer_irq(void)
>  /* Default timer init function */
>  void __init hpet_time_init(void)
>  {
> -	if (!hpet_enable())
> +	if (!hpet_enable() && !acpi_gbl_reduced_hardware)
>  		setup_pit_timer();
>  	setup_default_timer_irq();
>  }

So the whole acpi_gbl_reduced_hardware flaggery sucks as it mixes 
various hardware drivers that have little relation to each other...

Instead of having a proper platform init this flag hooks into various 
drivers and generic code, such as the efi reboot and shutdown code, 
and now the generic irq init code.

For this IRQ init problem, why not add a proper callback to 
x86_platform_ops, define your own IRQ init function, initialize it in 
your platform init sequence and let it be called? That solves it 
without creating an ugly mix of different platform methods.

For the EFI shutdown case, what's wrong with setting your own 
pm_power_off handler like most of the other platforms are doing? Plus 
the EFI code in drivers/firmware/efi/reboot.c should probably only set 
the shutdown handler if pm_power_off is still NULL.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/