On Thu, Oct 15, 2015 at 2:23 AM, Al Stone <ahs3@xxxxxxxxxx> wrote: > On 10/14/2015 05:44 PM, Rafael J. Wysocki wrote: >> On Wednesday, October 14, 2015 03:26:21 PM Al Stone wrote: >>> Once the patch series "Provide better MADT subtable sanity checks" got >>> into linux-next (commit b9e11e92b9), several existing platforms were found >>> where the firmware was doing odd things that aren't exactly correct if >>> the ACPI specification is being followed precisely. This patch series >>> relaxes some of the checks on MADT subtables so that these previously >>> working systems (all x86-based) will continue to boot. For arm64, since >>> ACPI usage is still relatively new, the stricter checking is left in place. >>> >>> Al Stone (4): >>> ACPI: workaround x86 firmware using reserved MADT subtable IDs >>> ACPI: workaround x86 firmware with mis-matched FADT/MADT revisions >>> ACPI: workaround FADT always being revision 2 >>> ACPI: for bad_madt_entry(), the GIC ITS table is 20 bytes long, not 16 >>> >>> drivers/acpi/tables.c | 62 ++++++++++++++++++++++++++++++++++++++++++--------- >>> 1 file changed, 51 insertions(+), 11 deletions(-) >> >> Honestly, having reviewed this series I'm inclined to drop the original >> changes from my tree and ask you to start over. > > Yeah, I'm leaning that way, too. This is getting way too messy. > >> It seems to have been a mistake to modify the existing behavior for x86 and >> goodness only knows about ia64. The changes for these architectures don't make >> us better off in any way. > > Right. It is truly amazing to me how much kruft this has turned up, when the > idea was simply to make sure that the tables used contain proper content -- and > this is only for one table. I understand why we don't want to break something > that's already working but I am just sort of amazed at how much improperly > written firmware is in use. I wanted to believe things were better than that. Well, actually, this is quite consistent with all of my previous experience as disappointing as that may be ... > Oh, well. I'll turn the optimism knob back down to 1 and the cynicism knob all > the way up to 11... > >> I understand the motivation to keep ARM64 "fresh and clean", but there must be >> a way to do that without affecting the other architectures negatively. >> >> Thanks, >> Rafael > > Let me think on that; it can be done, I'm sure, but part of the motivation for > these patches was that all architectures should follow the same ACPI rules. I > was honestly hoping to avoid a per architecture solution. That hasn't worked out well, though. Thanks, Rafael -- 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
