On Wednesday, May 19, 2010 09:43:11 am Matthew Garrett wrote: > Windows ignores everything but the lower 16 bits of system io accesses. > Enable compatibility with it if the firmware indicates Windows compatibility > by requesting a version of Windows via the _OSI method. > > Signed-off-by: Matthew Garrett <mjg@xxxxxxxxxx> > --- > drivers/acpi/bus.c | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c > index 743576b..a10144b 100644 > --- a/drivers/acpi/bus.c > +++ b/drivers/acpi/bus.c > @@ -904,6 +904,14 @@ static int __init acpi_bus_init(void) > goto error1; > } > > + /* > + * _SB_._INI has been called, so any _OSI requests should now have > + * been completed - enable any OS-specific workarounds > + */ > + > + if (acpi_gbl_osi_data >= ACPI_OSI_WIN_2000) > + acpi_gbl_ignore_high_ioport_bits = TRUE; What's the basis for the Win 2000 check? Is the intent that we do this for all Windows versions? Wikipedia claims Windows 98 had ACPI support, but there's no ACPI_OSI_WIN_98 definition. Is there a reason why we wouldn't just set ignore_high_ioport_bits = TRUE always? I'm sure you're doing this right; I'm just hoping for enough details that if we ever *do* have a valid IO address that doesn't fit in 16 bits, we'll be able to accomodate that without breaking old boxes again. 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
