On Wed, Nov 16, 2011 at 12:58 PM, Thomas Renninger <trenn@xxxxxxx> wrote: > On Wednesday 16 November 2011 16:45:11 Bjorn Helgaas wrote: >> We should try very hard to treat APEI generic address structures the >> same way as all others. If that means some machines need firmware >> upgrades or some sort of quirks to work around BIOS bugs, we might >> have to accept that. I think a single set of GAS accessors plus a few >> quirks that fix the GAS structures is far better than having >> APEI-specific GAS accessors that are basically tailored to a few >> broken machines. > That does not account that Windows possibly also has duplicated GAS > parsing code in their APEI subsystem/driver. > > Most APEI GAS structures have the mask value which makes bit_width > needless/redundant. > > It's not unlikely that: Windows only ignores > bit width on APEI GAS structures with a mask value (HEST table only?). > Then quirking specific BIOSes is a bad idea, we want to resolve this > in a generic way and the only possibility (as so often) could be to > do it the same way we expect Windows does it. And if they have > duplicated GAS parsing code, we might need it as well. > Therefore I would not rush with making APEI code using the generic > interfaces. Possibly it's even wrong and will never happen. > > I'd like to see an APEI GAS parsing code being able to handle all > (say as much as possible) APEI tables correctly first. There's a lot of speculation above about Windows duplicating GAS parsing, using mask instead of bit_width, etc. I don't think we have good evidence for it. In general, my experience is that Windows has a pretty high-quality ACPI implementation (though obviously it sometimes interprets things differently than Linux), so I hesitate to assume special cases like this in Windows. APEI support in BIOSes is immature, and I don't want to hard-code assumptions into Linux based on a few possibly defective BIOSes. Assumptions like that will constrain us in the future. >> Or maybe we could learn enough from a conversation with BIOS writers >> about how they interpret the spec and what they expect to happen with >> non-zero bit_offset and bit_width. > You could try at a conference after some beers... This is extra difficult, > because of the NDA coverage of the Whea spec. I disagree. The simple question "how do you expect the OS to interpret this GAS?" has nothing to do with any Windows NDA. You seem to have a nice collection of DSDT/APEI/etc tables. Can you get any idea of how many of them contain GAS structures that would break under my proposal (https://docs.google.com/spreadsheet/ccc?key=0AjvKas55tQpqdElKVXM2TEFVcnI3SjVuZ1pqUENMN1E)? Bjorn -- 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
