linux-kernel - raw_pci_read in quirk_intel

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: <20080210230204.GH5299@parisc-linux.org>
Date:	Sun, 10 Feb 2008 16:02:04 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Yinghai Lu <yhlu.kernel@...il.com>, Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Tony Camuso <tcamuso@...hat.com>,
	Grant Grundler <grundler@...isc-linux.org>,
	Loic Prylli <loic@...i.com>, Adrian Bunk <bunk@...nel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	Jeff Garzik <jeff@...zik.org>,
	linux-pci@...ey.karlin.mff.cuni.cz, Martin Mares <mj@....cz>
Subject: raw_pci_read in quirk_intel_irqbalance

On Sun, Feb 10, 2008 at 01:45:57PM -0700, Matthew Wilcox wrote:
> I just looked at fixing that -- the reason seems to be that we don't
> actually have the struct pci_dev at that point.  I can fix it, but I
> think it's actually buggy.  I want to look at some chipset docs to
> confirm that though.

I don't think I fully understand what's going on here.  So here's what
I've been able to glean; hopefully someone who understands this better
can help out.

I happen to have an E7525-based machine, so here's an lspci of bus 0:

00:00.0 Host bridge: Intel Corporation E7525 Memory Controller Hub (rev 0a)
00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 0a)
00:03.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A1 (rev 0a)
00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev 0a)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02)

The line in question reads:

        /* read xTPR register */
        raw_pci_read(0, 0, 0x40, 0x4c, 2, &word);

That's domain 0, bus 0, device 8, function 0, address 0x4c, length 2.

I've checked the public E7525 and E7520 MCH datasheets, and they don't
document the xTPR registers; nor do any of the devices in the datasheet
have registers documented at 0x4c.

You can see from my lspci above that I don't _have_ a device 8 on bus 0.
The aforementioned documentation says:

"A disabled or non-existent device's configuration register space is
hidden. A disabled or non-existent device will return all ones for reads
and will drop writes just as if the cycle terminated with a Master Abort
on PCI."

Now, my E7525 isn't affected by this quirk as it has a revision greater
than 0x9.  So maybe it's expected that device 8 is hidden on my machine;
that it's only present on revisions up to 0x9.  But maybe device 8 is
always hidden, and that's why the author used raw_pci_ops?

We can still do better than this, though.  We can do:

-	raw_pci_read(0, 0, 0x40, 0x4c, 2, &word);
+	pci_bus_read_config_word(dev->bus, PCI_DEVFN(8, 0), 0x4c, &word);

Using PCI_DEVFN tells people you really did mean device 8, and it's not
a braino for device 4 or 2 (how many bits for slot and function again?)

I'll see if I can dig up the internal documentation for the xTPR register
when I'm at work on Monday.  But I've never gone looking for internal
documentation before, so I have no idea how easy it will be to find ;-)

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/