On Tuesday 24 July 2007 12:17:36 pm Maciej W. Rozycki wrote:
> On Tue, 24 Jul 2007, Jeff Garzik wrote:
>
> > It seems clear from this report that we cannot, should not, trust BIOS for
> > something (a) so simple and (b) that has been working for over a decade.
>
> And (c) something BIOS writers have never ever in their most unlikely
> imagination expected to be trusted for.
I don't think it's quite so clear-cut. It is true that "poke at 0x3e8,
and if it responds, assume it's a 16550 with IRQ 4" is simple. But it
doesn't always work. Google for "irda setserial" and you'll find many
cases where the serial driver's blind probe erroneously claims an IRDA
device. The SIR mode of IRDA devices is basically 16550-compatible,
so this wouldn't be a big problem, except that the blind probe often
assumes the wrong IRQ. So users have to use setserial to fix up the
incorrect assumptions made by the blind probe.
We haven't debugged the problem on Sebastien's machine yet. I suspect
we'll find that his serial port *is* described by ACPI, but that there's
some little difference in the way Linux discovers those devices compared
to how Windows does it. If we figure out how to use ACPI more like
Windows does, I think we'll fix several little issues, including the one
on Sebastien's machine.
We have a whole laundry list of minor issues because we either don't
listen to the BIOS at all, or we use it differently than Windows does.
Here are a few off the top of my head:
- IRDA drivers have platform-specific code to "preconfigure" (discover
and reprogram) bridges on the way to the IR device
- Hardware sensor drivers conflict with ACPI embedded controller
drivers, so every once in a while, they return bogus readings
- PCMCIA devices grab resources already in use by a PNP device,
causing the PNP device to stop working
- Linux enumerates CPUs with the MADT; I think Windows uses the ACPI
namespace. Sometimes there are multiple MADTs, and sometimes Linux
uses the wrong one.
If we keep papering over these problems by ignoring what ACPI is trying
to tell us, we're going to be adding machine-specific hacks forever.
Of course, there are ACPI bugs. But Windows does rely on ACPI, and
Microsoft doesn't want to add those per-platform hacks any more than
we do. So we might as well try to take advantage of the ACPI testing
they do.
Bjorn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
