linux-kernel - Re: [PATCH 1/1] PCI: tune up ICH4 quirk for broken BIOSes

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]

Date:	Thu, 13 Jan 2011 16:15:20 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Jiri Slaby <jirislaby@...il.com>, Jiri Slaby <jslaby@...e.cz>,
	jbarnes@...tuousgeek.org, linux-pci@...r.kernel.org,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Thomas Renninger <trenn@...e.de>
Subject: Re: [PATCH 1/1] PCI: tune up ICH4 quirk for broken BIOSes

On Thu, Jan 13, 2011 at 3:19 PM, Bjorn Helgaas <bjorn.helgaas@...com> wrote:
>
> I think we're back to the question of why we have the ICH4 quirk in
> the first place, and I don't know the answer to that.

Iirc, there were several laptops that didn't have the ACPI region
mentioned in any of the regular places, and we'd allocate the PCMCIA
IO region on top of them. The machine would boot, but if anybody ever
inserted a PCCard into the machine, the first access to the IO region
would generally just halt it (because it was trying to read the
PCCard, but the APCI region decodes first, and then the read from that
usually put the CPU in a sleep state that it would never wake up from
for obvious reasons).

So we do want the ICH4 quirk.

> Maybe you could make the ICH4 quirk only claim the region if it's
> above PCIBIOS_MIN_IO, i.e., if it's in the area where we could put
> another PCI device on top of it?

That may well be the best solution - we'd only mark it reserved if it
might conflict with a dynamic allocation, and if it conflicts with
other motherboard resources (like the IDE ports), then we don't know
what the decode priority is anyway, so..

In this case, it looks like the legacy IDE ports get decoded before
the dynamic BAR's. Which is not too much of a surprise (fixed
addresses tend to be the first to get decoded).

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