Since we may not have a pci_dev for the device we need to access, we can't
use pci_read_config_word.  But raw_pci_read is an internal implementation
detail; it's better to use the architected pci_bus_read_config_word
interface.  Using PCI_DEVFN instead of a mysterious constant helps
reassure everyone that we really do intend to access device 8.

[ Thanks to Grant Grundler for pointing out to me that this is exactly
  what the write immediately above this is doing -- enabling device 8 to
  respond to config space cycles.
					- Matthew

  Grant also says:

	"Can you also add a comment which points at the Intel
	 documentation?

	 The 'Intel E7320 Memory Controller Hub (MCH) Datasheet' at

	  http://download.intel.com/design/chipsets/datashts/30300702.pdf

	 Page 69 documents register F4h (DEVPRES1).

	 And I just doubled checked that the 0xf4 register value is
	 restored later in the quirk (obvious when you look at the code
	 but not from the patch"

  so here it is.
					 - Linus ]
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Acked-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>