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
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
i386 [PATCH] remove special HPET_EMULATE_RTC config option 2005-08-04 16:27:58 -07:00
ia64
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
mips
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
sh64 It wasn't just x86-64 that had hardcoded VM_FAULT_xxx numbers 2005-08-04 08:33:38 -07:00
sparc
sparc64 [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it 2005-08-04 21:32:46 -07:00
um
v850
x86_64 [PATCH] x86_64: fix 32-bit thread debugging 2005-08-04 16:28:27 -07:00
xtensa