[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A0C584E.2060409@kernel.org>
Date: Thu, 14 May 2009 10:43:42 -0700
From: Yinghai Lu <yinghai@...nel.org>
To: Len Brown <lenb@...nel.org>
CC: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-pci@...r.kernel.org,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH 2/7] x86/acpi: calling mp_config_acpi_gsi in mp_register_gsi
-v2
Len Brown wrote:
> mp_config_acpi_gsi() has been dead code since the day it went into 2.6.27.
> Rather than repairing that, I'd rather see it removed.
>
> The justification for 2944e16b25e7fb8b5ee0dd9dc7197a0f9e523cfd
> "x86: update mptable" was:
>
> 1. kexec kernel with acpi=off
> 2. work around BIOSes where acpi routing is working, but mptable is
> not right, so can use kernel/kexec to start other OSes that don't have
> good acpi support.
>
> command line: update_mptable
>
> So this is a command line option to allow
> MPS code to call into ACPI code to support kexec from an ACPI
> mode into non-ACPI mode -- all without a single comment in the code.
>
> I'm not convinced that the scenario that this code was
> intended to address justifies adding unreadable code to
> an area of the kernel which is notoriously over-complicated
> and fragile. Doing so is the opposite of optimizing for maintenance.
also could use it to show BIOS engineers what is correct mptable and that could help them to
fix the problem in mptable creating when the system have a lot pci cards with bridge in the card.
>
> No, I don't want to see any MPS code ever call into ACPI code.
how about:
make enable_update_mptable global, and in mp_register_gsi only call mp_config_acpi_gsi()
when enable_update_mptable == 1
YH
--
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/
Powered by blists - more mailing lists