aboutsummaryrefslogtreecommitdiff
path: root/arch/x86/pci/pcbios.c
AgeCommit message (Collapse)Author
2009-01-29x86: move mach-default/*.h files to asm/Ingo Molnar
We are getting rid of subarchitecture support - move the hook files to asm/. (These are now stale and should be replaced with more explicit runtime mechanisms - but the transition is simpler this way.) Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-29x86, pci: move arch/x86/pci/pci.h to arch/x86/include/asm/pci_x86.hJaswinder Singh Rajput
Impact: cleanup Now that arch/x86/pci/pci.h is used in a number of other places as well, move the lowlevel x86 pci definitions into the architecture include files. (not to be confused with the existing arch/x86/include/asm/pci.h file, which provides public details about x86 PCI) Tested on: X86_32_UP, X86_32_SMP and X86_64_SMP Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-20PCI: remove initial bios sort of PCI devices on x86Greg Kroah-Hartman
We currently keep 2 lists of PCI devices in the system, one in the driver core, and one all on its own. This second list is sorted at boot time, in "BIOS" order, to try to remain compatible with older kernels (2.2 and earlier days). There was also a "nosort" option to turn this sorting off, to remain compatible with even older kernel versions, but that just ends up being what we have been doing from 2.5 days... Unfortunately, the second list of devices is not really ever used to determine the probing order of PCI devices or drivers[1]. That is done using the driver core list instead. This change happened back in the early 2.5 days. Relying on BIOS ording for the binding of drivers to specific device names is problematic for many reasons, and userspace tools like udev exist to properly name devices in a persistant manner if that is needed, no reliance on the BIOS is needed. Matt Domsch and others at Dell noticed this back in 2006, and added a boot option to sort the PCI device lists (both of them) in a breadth-first manner to help remain compatible with the 2.4 order, if needed for any reason. This option is not going away, as some systems rely on them. This patch removes the sorting of the internal PCI device list in "BIOS" mode, as it's not needed at all anymore, and hasn't for many years. I've also removed the PCI flags for this from some other arches that for some reason defined them, but never used them. This should not change the ordering of any drivers or device probing. [1] The old-style pci_get_device and pci_find_device() still used this sorting order, but there are very few drivers that use these functions, as they are deprecated for use in this manner. If for some reason, a driver rely on the order and uses these functions, the breadth-first boot option will resolve any problem. Cc: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-10fix BIOS PCI config cycle buglet causing ACPI boot regressionIngo Molnar
I figured out another ACPI related regression today. randconfig testing triggered an early boot-time hang on a laptop of mine (32-bit x86, config attached) - the screen was scrolling ACPI AML exceptions [with no serial port and no early debugging available]. v2.6.24 works fine on that laptop with the same .config, so after a few hours of bisection (had to restart it 3 times - other regressions interacted), it honed in on this commit: | 10270d4838bdc493781f5a1cf2e90e9c34c9142f is first bad commit | | Author: Linus Torvalds <torvalds@woody.linux-foundation.org> | Date: Wed Feb 13 09:56:14 2008 -0800 | | acpi: fix acpi_os_read_pci_configuration() misuse of raw_pci_read() reverting this commit ontop of -rc5 gave a correctly booting kernel. But this commit fixes a real bug so the real question is, why did it break the bootup? After quite some head-scratching, the following change stood out: - pci_id->bus = tu8; + pci_id->bus = val; pci_id->bus is defined as u16: struct acpi_pci_id { u16 segment; u16 bus; ... and 'tu8' changed from u8 to u32. So previously we'd unconditionally mask the return value of acpi_os_read_pci_configuration() (raw_pci_read()) to 8 bits, but now we just trust whatever comes back from the PCI access routines and only crop it to 16 bits. But if the high 8 bits of that result contains any noise then we'll write that into ACPI's PCI ID descriptor and confuse the heck out of the rest of ACPI. So lets check the PCI-BIOS code on that theory. We have this codepath for 8-bit accesses (arch/x86/pci/pcbios.c:pci_bios_read()): switch (len) { case 1: __asm__("lcall *(%%esi); cld\n\t" "jc 1f\n\t" "xor %%ah, %%ah\n" "1:" : "=c" (*value), "=a" (result) : "1" (PCIBIOS_READ_CONFIG_BYTE), "b" (bx), "D" ((long)reg), "S" (&pci_indirect)); Aha! The "=a" output constraint puts the full 32 bits of EAX into *value. But if the BIOS's routines set any of the high bits to nonzero, we'll return a value with more set in it than intended. The other, more common PCI access methods (v1 and v2 PCI reads) clear out the high bits already, for example pci_conf1_read() does: switch (len) { case 1: *value = inb(0xCFC + (reg & 3)); which explicitly converts the return byte up to 32 bits and zero-extends it. So zero-extending the result in the PCI-BIOS read routine fixes the regression on my laptop. ( It might fix some other long-standing issues we had with PCI-BIOS during the past decade ... ) Both 8-bit and 16-bit accesses were buggy. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-11i386: move pciThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>