On 11/13/2013 02:28 AM, Hanjun Guo wrote:
On 2013-11-13 11:16, al.stone@linaro.org wrote:
From: Al Stone ahs3@redhat.com
Signed-off-by: Al Stone al.stone@linaro.org
drivers/acpi/bus.c | 3 ++- drivers/acpi/osl.c | 10 ++++++---- drivers/acpi/pci_link.c | 14 ++++++++------ 3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 439c369..7fcbc6a 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -543,7 +543,8 @@ void __init acpi_early_init(void) goto error0; }
-#ifdef CONFIG_X86 +#if (!CONFIG_ACPI_REDUCED_HARDWARE)
CONFIG_X86 is definitely *not* reduced hardware, why should we change it here?
The reasoning is: x86 is not yet reduced HW; there are rumors that such chips are either out there or coming. In that case, there could be an x86 machine that _is_ reduced hardware and I do not want to preclude that case.
Does that make sense?
- /* NB: in HW reduced mode, FADT sci_interrupt has no meaning */ if (!acpi_ioapic) { /* compatible (0) means level (3) */ if (!(acpi_sci_flags & ACPI_MADT_TRIGGER_MASK)) {
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index 34beeba..75da583 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -85,6 +85,7 @@ static int (*__acpi_os_prepare_extended_sleep)(u8 sleep_state, u32 val_a,
static acpi_osd_handler acpi_irq_handler; static void *acpi_irq_context; +static u32 acpi_irq_number; static struct workqueue_struct *kacpid_wq; static struct workqueue_struct *kacpi_notify_wq; static struct workqueue_struct *kacpi_hotplug_wq; @@ -841,9 +842,9 @@ acpi_os_install_interrupt_handler(u32 gsi, acpi_osd_handler handler,
/* * ACPI interrupts different from the SCI in our copy of the FADT are
* not supported.
* not supported, except in HW reduced mode.
- if (gsi != acpi_gbl_FADT.sci_interrupt)
if (!acpi_gbl_reduced_hardware && (gsi != acpi_gbl_FADT.sci_interrupt)) return AE_BAD_PARAMETER;
if (acpi_irq_handler)
@@ -862,13 +863,14 @@ acpi_os_install_interrupt_handler(u32 gsi, acpi_osd_handler handler, acpi_irq_handler = NULL; return AE_NOT_ACQUIRED; }
acpi_irq_number = irq;
return AE_OK; }
acpi_status acpi_os_remove_interrupt_handler(u32 irq, acpi_osd_handler handler) {
- if (irq != acpi_gbl_FADT.sci_interrupt)
if (!acpi_gbl_reduced_hardware && (irq != acpi_gbl_FADT.sci_interrupt)) return AE_BAD_PARAMETER;
free_irq(irq, acpi_irq);
@@ -1845,7 +1847,7 @@ acpi_status __init acpi_os_initialize1(void) acpi_status acpi_os_terminate(void) { if (acpi_irq_handler) {
acpi_os_remove_interrupt_handler(acpi_gbl_FADT.sci_interrupt,
acpi_os_remove_interrupt_handler(acpi_irq_number, acpi_irq_handler);diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c index 2652a61..c0ab28a 100644 --- a/drivers/acpi/pci_link.c +++ b/drivers/acpi/pci_link.c @@ -23,7 +23,7 @@
- TBD:
- TBD:
[...]
- /*
* Query and parse _CRS to get the current IRQ assignment.
- /*
* Query and parse _CRS to get the current IRQ assignment.[...]
Interesting, it seems that you have a auto running script to fix tailing blank problem.
I may not do that, because it will distract the attention from the patch itself.
Thanks Hanjun
Yow! Where did that come from? I'm wondering if rebase is doing something or this is more PEBKAC. I'll look into it for the next version.