linux-kernel - Re: commit 7e92b4fc34 - x86, serial: convert legacy COM ports to platform devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200707241353.57458.bjorn.helgaas@hp.com>
Date:	Tue, 24 Jul 2007 13:53:57 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
Cc:	Jeff Garzik <jeff@...zik.org>,
	Sébastien Dugué <sebastien.dugue@...l.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: commit 7e92b4fc34 - x86, serial: convert legacy COM ports to platform devices - broke my serial console

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 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/