mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-11-20 16:46:23 +08:00
9585ca02f8
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: Matthew Wilcox <willy@linux.intel.com> Acked-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
||
---|---|---|
.. | ||
alpha | ||
arm | ||
avr32 | ||
blackfin | ||
cris | ||
frv | ||
h8300 | ||
ia64 | ||
m32r | ||
m68k | ||
m68knommu | ||
mips | ||
mn10300 | ||
parisc | ||
powerpc | ||
ppc | ||
s390 | ||
sh | ||
sparc | ||
sparc64 | ||
um | ||
v850 | ||
x86 | ||
xtensa | ||
.gitignore | ||
Kconfig |