kernel_optimize_test/arch
John W. Linville fec59a711e [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it
Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
(including BARs) when transitioning from D3hot->D0.  This leaves such
a device in an inaccessible state.  The patch below causes the BARs
to be restored when enabling such a device, so that its driver will
be able to access it.

The patch also adds pci_restore_bars as a new global symbol, and adds a
correpsonding EXPORT_SYMBOL_GPL for that.

Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a
(re)boot.  Most drivers call pci_enable_device very early, so devices
left in D3hot that lose configuration during the D3hot->D0 transition
will be inaccessible to their drivers.

Drivers could be modified to account for this, but it would
be difficult to know which drivers need modification.  This is
especially true since often many devices are covered by the same
driver.  It likely would be necessary to replicate code across dozens
of drivers.

The patch below should trigger only when transitioning from D3hot->D0
(or at boot), and only for devices that have the "no soft reset" bit
cleared in the PM control register.  I believe it is safe to include
this patch as part of the PCI infrastructure.

The cleanest implementation of pci_restore_bars was to call
pci_update_resource.  Unfortunately, that does not currently exist
for the sparc64 architecture.  The patch below includes a null
implemenation of pci_update_resource for sparc64.

Some have expressed interest in making general use of the the
pci_restore_bars function, so that has been exported to GPL licensed
modules.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-04 21:32:46 -07:00
..
alpha [PATCH] new alpha syscalls 2005-07-27 18:24:24 -07:00
arm [PATCH] ARM: 2844/1: Add maintainer for Jornada 720 2005-08-04 20:43:40 +01:00
arm26 It wasn't just x86-64 that had hardcoded VM_FAULT_xxx numbers 2005-08-04 08:33:38 -07:00
cris It wasn't just x86-64 that had hardcoded VM_FAULT_xxx numbers 2005-08-04 08:33:38 -07:00
frv It wasn't just x86-64 that had hardcoded VM_FAULT_xxx numbers 2005-08-04 08:33:38 -07:00
h8300 [PATCH] Don't export machine_restart, machine_halt, or machine_power_off. 2005-07-26 14:35:42 -07:00
i386 [PATCH] remove special HPET_EMULATE_RTC config option 2005-08-04 16:27:58 -07:00
ia64 [PATCH] remove sys_set_zone_reclaim() 2005-08-01 10:03:56 -07:00
m32r [PATCH] m32r: Fix local-timer event handling 2005-08-01 21:37:59 -07:00
m68k It wasn't just x86-64 that had hardcoded VM_FAULT_xxx numbers 2005-08-04 08:33:38 -07:00
m68knommu [PATCH] Don't export machine_restart, machine_halt, or machine_power_off. 2005-07-26 14:35:42 -07:00
mips [PATCH] mips: remove obsolete GIU driver for vr41xx 2005-07-27 16:25:58 -07:00
parisc It wasn't just x86-64 that had hardcoded VM_FAULT_xxx numbers 2005-08-04 08:33:38 -07:00
ppc [PATCH] ppc32: add bamboo defconfig 2005-08-01 19:14:01 -07:00
ppc64 [PATCH] ppc64: fix for kexec boot issue 2005-08-04 13:00:55 -07:00
s390 [PATCH] s390: ioprio & inotify system calls. 2005-08-01 21:37:59 -07:00
sh [PATCH] try_to_freeze() call fixes 2005-07-27 16:25:49 -07:00
sh64 It wasn't just x86-64 that had hardcoded VM_FAULT_xxx numbers 2005-08-04 08:33:38 -07:00
sparc [SPARC]: Add inotify syscall entries. 2005-07-27 14:14:39 -07:00
sparc64 [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it 2005-08-04 21:32:46 -07:00
um [PATCH] uml: fix vsyscall brokenness 2005-07-29 15:01:14 -07:00
v850 [PATCH] v850: Update PCI support 2005-07-27 16:26:03 -07:00
x86_64 [PATCH] x86_64: fix 32-bit thread debugging 2005-08-04 16:28:27 -07:00
xtensa [PATCH] xtensa: use ssleep() instead of schedule_timeout() 2005-07-12 16:01:01 -07:00