The correct order is: NULL check before dereference

Spotted by the Coverity checker.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch fixes the problem that "irq XX: nobody cared" kernel oops
is reported when pciehp is once rmmoded and insmoded again. The cause
of this problem is pciehp driver calls pci_disable_msi() at controller
release time, even though it must be done by PCI Express Port Bus
driver. This patch removes unnecessary pci_disable_msi() call from
pciehp driver.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch fixes the problem that the following error messages is
reported when pciehp driver is rmmoded.

	Trying to free already-free IRQ XX

The cause of this problem is that pciehp driver is doing unknown 2nd
free_irq at driver unloading. This patch removes this unknown 2nd
free_irq call.

Note: The pciehp driver should be adapted to standard device driver
mode.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change the criterion that RPA PCI Hotplug and RPA DLPAR use when
determining the hotplug capabilities of a given device node.  The
"device_type" property is less consistent than "name" across PCI nodes
on newer hardware.
Signed-off-by: NJohn Rose <johnrose@austin.ibm.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change memory allocation for acpiphp slots

Change the "struct slot" that acpiphp uses for managing it's slots to
directly contain the memory for the needed struct hotplug_slot_info and
the slot's name. This way we need only two memory allocations per slot
instead of four.

While we are at it: make_slot_name() is just a wrapper around snprintf()
knowing the right arguments to call it. Since the function makes just one
function call and is only called from one place I inlined it by hand.

Finally this fixes a possible bug waiting for someone to hit it. There were
two unused local variables in acpiphp_register_hotplug_slot(). gcc did not
find them because they were used in memory allocations with sizeof(*var).
They had the same types as the target of the allocation, but nevertheless
this was just weird.
Signed-off-by: NRolf Eike Beer <eike-hotplug@sf-tec.de>
Acked-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Changes the pci_{enable,disable}_device() functions to work in a
nested basis, so that eg, three calls to enable_device() require three
calls to disable_device().

The reason for this is to simplify PCI drivers for
multi-interface/capability devices. These are devices that cram more
than one interface in a single function. A relevant example of that is
the Wireless [USB] Host Controller Interface (similar to EHCI) [see
http://www.intel.com/technology/comms/wusb/whci.htm]. 

In these kind of devices, multiple interfaces are accessed through a
single bar and IRQ line. For that, the drivers map only the smallest
area of the bar to access their register banks and use shared IRQ
handlers. 

However, because the order at which those drivers load cannot be known
ahead of time, the sequence in which the calls to pci_enable_device()
and pci_disable_device() cannot be predicted. Thus:

1. driverA     starts     pci_enable_device()
2. driverB     starts     pci_enable_device()
3. driverA     shutdown   pci_disable_device()
4. driverB     shutdown   pci_disable_device()

between steps 3 and 4, driver B would loose access to it's device,
even if it didn't intend to.

By using this modification, the device won't be disabled until all the
callers to enable() have called disable().

This is implemented by replacing 'struct pci_dev->is_enabled' from a
bitfield to an atomic use count. Each caller to enable increments it,
each caller to disable decrements it. When the count increments from 0
to 1, __pci_enable_device() is called to actually enable the
device. When it drops to zero, pci_disable_device() actually does the
disabling.

We keep the backend __pci_enable_device() for pci_default_resume() to
use and also change the sysfs method implementation, so that userspace
enabling/disabling the device doesn't disable it one time too much.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The existing implementation of pci_block_user_cfg_access() was recently
criticised for providing out of date information and for returning errors
on write, which applications won't be expecting.

This reimplementation uses a global wait queue and a bit per device.
I've open-coded prepare_to_wait() / finish_wait() as I could optimise
it significantly by knowing that the pci_lock protected us at all points.

It looked a bit funny to be doing a spin_unlock_irqsave(); schedule(),
so I used spin_lock_irq() for the _user versions of pci_read_config and
pci_write_config.  Not carrying a flags pointer around made the code
much less nasty.

Attempts to block an already blocked device hit a BUG() and attempts to
unblock an already unblocked device hit a WARN().  If we need to block
access to a device from userspace, it's because it's unsafe for even
another bit of the kernel to access the device.  An attempt to block
a device for a second time means we're about to access the device to
perform some other operation, which could provoke undefined behaviour
from the device.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Acked-by: NAdam Belay <abelay@novell.com>
Acked-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

__pci_register_driver() error path forgot to unwind.
driver_unregister() needs to be called when pci_create_newid_file() failed.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

So it looks like pci aer code will call pci_osc_support_set to tell the
firmware about  OSC_EXT_PCI_CONFIG_SUPPORT flag.  that causes
ctrlset_buf[OSC_SUPPORT_TYPE] to evaluate to true when pciehp calls
pci_osc_control_set() is called (to attempt to use OSC to gain native
pcie control from firmware), regardless of whether or not _OSC was
actually successfully executed.  That causes this section of code:
 if (ctrlset_buf[OSC_SUPPORT_TYPE] &&
                ((global_ctrlsets & ctrlset) != ctrlset)) {
                return AE_SUPPORT;
        }
to be hit.

This patch will reset the OSC_SUPPORT_TYPE field if _OSC fails, and then
would allow pciehp to go ahead and try to run _OSC again.
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

acpiphp_glue_exit() needs to be called to unwind when no slots found.
(It fixes data corruption when reloading acpiphp driver with no such devices)
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch fixes invalid usage of list_for_each()

list_for_each (node, &bridge_list) {
	bridge = (struct acpiphp_bridge *)node;
	...
}

This code works while the member of list node is located at the
head of struct acpiphp_bridge.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Support a shadowed ROM when running with an ACPI capable PROM.

Define a new dev.resource flag IORESOURCE_ROM_BIOS_COPY to
describe the case of a BIOS shadowed ROM, which can then
be used to avoid pci_map_rom() making an unneeded call to
pci_enable_rom().
Signed-off-by: NJohn Keller <jpk@sgi.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

A few minor changes to the way slot/device fixup is done.

No need to be calling sn_pci_controller_fixup(), as
a root bus cannot be hotplugged.
Signed-off-by: NJohn Keller <jpk@sgi.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

pSeries is the only architecture left using HAVE_ARCH_PCI_MWI and it's
really inappropriate for its needs.  It really wants to disable MWI
altogether.  So here are a pair of stub implementations for pci_set_mwi
and pci_clear_mwi.

Also rename pci_generic_prep_mwi to pci_set_cacheline_size since that
better reflects what it does.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Cc: Paul Mackerras <paulus@samba.org>
Acked-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The setting of the CACHE_LINE_SIZE register in sparc64's pci
initialisation code isn't quite adequate as the device may have
incompatible requirements.  The generic code tests for this, so switch
sparc64 over to using it.

Since sparc64 has different L1 cache line size and PCI cache line size,
it would need to override the generic code like i386 and ia64 do.  We
know what the cache line size is at compile time though, so introduce a
new optional constant PCI_CACHE_LINE_BYTES.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NDavid Miller <davem@davemloft.net>
Acked-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The number of permutations of crap we do is amazing and almost all of it
has the wrong effect in 2.6.

At the heart of this is the PCI SFF magic which says that compatibility
mode PCI IDE controllers use ISA IRQ routing and hard coded addresses
not the BAR values. The old quirks variously clears them, sets them,
adjusts them and then IDE ignores the result.

In order to drive all this garbage out and to do it portably we need to
handle the SFF rules directly and properly. Because we know the device
BAR 0-3 are not used in compatibility mode we load them with the values
that are implied (and indeed which many controllers actually
thoughtfully put there in this mode anyway).

This removes special cases in the IDE layer and libata which now knows
that bar 0/1/2/3 always contain the correct address. It means our
resource allocation map is accurate from boot, not "mostly accurate"
after ide is loaded, and it shoots lots of code. There is also lots more
code and magic constant knowledge to shoot once this is in and settled.

Been in my test tree for a while both with drivers/ide and with libata.
Wants some -mm shakedown in case I've missed something dumb or there are
corner cases lurking.
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Shouldn't PCI-X state be saved/restored?  No device really needs this
right now. qla24xx (fc HBA) and mthca (infiniband) don't do suspend, 
and sky2 resets its tweaks when links are brought up.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Move some MSI-X #defines into pci_regs.h so they can be used
outside of drivers/pci.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

It's not really broken, but people keep running into other problems
caused by it.  Re-enable it so that the drivers get stress tested.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Changes persistant -> persistent. www.dictionary.com does not know
persistant (with an A), but should it be one of those things you can
spell in more than one correct way, let me know.
Signed-off-by: NJan Engelhardt <jengelh@gmx.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Fix various .c/.h typos in comments (no code changes).
Signed-off-by: NMatt LaPlante <kernel1@cyberdogtech.com>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Fix various Kconfig typos.
Signed-off-by: NMatt LaPlante <kernel1@cyberdogtech.com>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Fix http://bugzilla.kernel.org/show_bug.cgi?id=7264

We need to target this quirk a little more tightly, using the T20 DMI string.

Cc: Pavel Kysilka <goldenfish@bsys.cz>
Acked-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Daniel Ritz <daniel.ritz@gmx.ch>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The PCI sysfs attributes are created after the initial PCI bus scan.  With
the addition of more return value checking and assertions in the device and
sysfs layers we now can get dumps like this on sparc64:

[   20.135032] Call Trace:
[   20.135042]  [0000000000537f88] pci_remove_bus_device+0x30/0xc0
[   20.135076]  [000000000078f890] pci_fill_in_pbm_cookies+0x98/0x440
[   20.135109]  [000000000042e828] sabre_scan_bus+0x230/0x400
[   20.135139]  [000000000078c710] pcibios_init+0x58/0xa0
[   20.135159]  [0000000000416f14] init+0x9c/0x2e0
[   20.135190]  [0000000000417a50] kernel_thread+0x38/0x60
[   20.135211]  [0000000000417170] rest_init+0x18/0x40
[   20.135514] PCI0(PBMB): Bus running at 33MHz

It's triggering because removal of the "config" PCI sysfs file for the
device fails.

On sparc64, after probing the device, we'll delete the PCI device via
pci_remove_bus_device() if we cannot find the firmware device tree node
corresponding to it.

This is fine, but at this point the sysfs files for the PCI device won't be
setup yet.

So we should not try to do anything in pci_remove_sysfs_dev_files() if
pci_sysfs_init() has not run yet.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch adds a variant of ht_create_irq __ht_create_irq that takes an
aditional parameter update that is a function that is called whenever we want
to write to a drivers htirq configuration registers.

This is needed to support the ipath_iba6110 because it's registers in the
proper location are not actually conected to the hardware that controlls
interrupt delivery.

[bos@serpentine.com: fixes]
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Andi Kleen <ak@suse.de>
Cc: <olson@pathscale.com>
Cc: Roland Dreier <rolandd@cisco.com>
Signed-off-by: NBryan O'Sullivan <bryan.osullivan@qlogic.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This refactoring actually optimizes the code a little by caching the value
that we think the device is programmed with instead of reading it back from
the hardware.  Which simplifies the code a little and should speed things up a
bit.

This patch introduces the concept of a ht_irq_msg and modifies the
architecture read/write routines to update this code.

There is a minor consistency fix here as well as x86_64 forgot to initialize
the htirq as masked.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Andi Kleen <ak@suse.de>
Acked-by: NBryan O'Sullivan <bos@pathscale.com>
Cc: <olson@pathscale.com>
Cc: Roland Dreier <rolandd@cisco.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

PCI_MULTITHREAD_PROBE is an interesting feature, but in its current state
it seems to be more of a trap for users who accidentally enable it.

This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19.

The intention is to get this patch reversed in -mm as soon as it's in
Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of
in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed.

(akpm: I get enough bug reports already)
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

My K8T800 mobo resumes fine from suspend to ram with and without patch
applied against 2.6.18.

quirk_via_abnormal_poweroff makes some boards not boot 2.6.18, so IMO patch
should go to head, 2.6.18.2 and everywhere "ACPI: ACPICA 20060623" has been
applied.


Remove quirk_via_abnormal_poweroff

Obsoleted by "ACPI: ACPICA 20060623":
<snip>
    Implemented support for "ignored" bits in the ACPI
    registers.  According to the ACPI specification, these
    bits should be preserved when writing the registers via
    a read/modify/write cycle. There are 3 bits preserved
    in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9],
    and PM1_STATUS[11].
    http://bugzilla.kernel.org/show_bug.cgi?id=3691
</snip>
Signed-off-by: NKarsten Wiese <fzu@wemgehoertderstaat.de>
Cc: Bob Moore <robert.moore@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>
Acked-by: NDave Jones <davej@redhat.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Considering below scenario:
1.Unload a PCI device's driver, the device ->current remains in PCI_D0.
2.Do suspend/resume circle. After that, BIOS puts the device to D3.
3.Reload the device driver. The calling pci_set_power_state in the
driver can't change the state to D0, as set_power_state thinks the
device is already in D0.

A bug is reported at http://bugzilla.kernel.org/show_bug.cgi?id=6024
Pat attached a patch at
http://marc.theaimsgroup.com/?l=linux-pci&m=114049761428561&w=2 for this
issue, but it's lost. As pci_set_power_state can handle D3 -> D0
correctly (restore config space), I simplified Patrick's patch.
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Cc: Patrick Mochel <mochel@digitalimplant.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts much of the original pci_fixup_video change and makes it
work for all arches that need it.

fixed, and tested on x86, x86_64 and IA64 dig.
Signed-off-by: NEiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com>
Acked-by: NDavid Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

pci_hotplug.h says:

 * @latch_status: if the latch (if any) is open or closed (1/0)

However, acpiphp returns opposite value.
This patch fixes this issue.

I tested this patch on my ia64 machine that has some apciphp based
hotplug slots.
Signed-off-by: NMUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In commit 4e8a5201 ("[PKT_SCHED] netem:
Orphan SKB when adding to queue.") Davem mistakenly also included a
temporary diff in his tree that disabled the pci_fixup_video VGA quirk,
which broke sparc64.

This reverts that part of the commit. Sayeth Davem:

  "Greg KH has a patch coming to you soon which will move that VGA code
   back into x86/x86_64/IA64 specific areas and will fix the sparc64
   problem properly."

Special thanks to Claudio Martins <ctpm@ist.utl.pt> for noticing the
error in the first place.

Cc: Claudio Martins <ctpm@ist.utl.pt>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The networking emulator can queue SKBs for a very long
time, so if you're using netem on the sender side for
large bandwidth/delay product testing, the SKB socket
send queue sizes become artificially larger.

Correct this by calling skb_orphan() in netem_enqueue().
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use grep instead of make during interface changes.
Signed-off-by: NOlaf Hering <olaf@aepfle.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This makes it possible to build pci hotplug drivers outside of the main
kernel tree, and Sam keeps telling me to move local header files to
their proper places...
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Here's a patch adding me to the maintainers file for the pci
hotplug subsystem, as we discussed.
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Problem:
New Dell PowerEdge servers have 2 embedded ethernet ports, which are
labeled NIC1 and NIC2 on the chassis, in the BIOS setup screens, and
in the printed documentation.  Assuming no other add-in ethernet ports
in the system, Linux 2.4 kernels name these eth0 and eth1
respectively.  Many people have come to expect this naming.  Linux 2.6
kernels name these eth1 and eth0 respectively (backwards from
expectations).  I also have reports that various Sun and HP servers
have similar behavior.


Root cause:
Linux 2.4 kernels walk the pci_devices list, which happens to be
sorted in breadth-first order (or pcbios_find_device order on i386,
which most often is breadth-first also).  2.6 kernels have both the
pci_devices list and the pci_bus_type.klist_devices list, the latter
is what is walked at driver load time to match the pci_id tables; this
klist happens to be in depth-first order.

On systems where, for physical routing reasons, NIC1 appears on a
lower bus number than NIC2, but NIC2's bridge is discovered first in
the depth-first ordering, NIC2 will be discovered before NIC1.  If the
list were sorted breadth-first, NIC1 would be discovered before NIC2.

A PowerEdge 1955 system has the following topology which easily
exhibits the difference between depth-first and breadth-first device
lists.

-[0000:00]-+-00.0  Intel Corporation 5000P Chipset Memory Controller Hub
           +-02.0-[0000:03-08]--+-00.0-[0000:04-07]--+-00.0-[0000:05-06]----00.0-[0000:06]----00.0  Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC2, 2.4 kernel name eth1, 2.6 kernel name eth0)
           +-1c.0-[0000:01-02]----00.0-[0000:02]----00.0  Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC1, 2.4 kernel name eth0, 2.6 kernel name eth1)


Other factors, such as device driver load order and the presence of
PCI slots at various points in the bus hierarchy further complicate
this problem; I'm not trying to solve those here, just restore the
device order, and thus basic behavior, that 2.4 kernels had.


Solution:

The solution can come in multiple steps.

Suggested fix #1: kernel
Patch below optionally sorts the two device lists into breadth-first
ordering to maintain compatibility with 2.4 kernels.  It adds two new
command line options:
  pci=bfsort
  pci=nobfsort
to force the sort order, or not, as you wish.  It also adds DMI checks
for the specific Dell systems which exhibit "backwards" ordering, to
make them "right".


Suggested fix #2: udev rules from userland
Many people also have the expectation that embedded NICs are always
discovered before add-in NICs (which this patch does not try to do).
Using the PCI IRQ Routing Table provided by system BIOS, it's easy to
determine which PCI devices are embedded, or if add-in, which PCI slot
they're in.  I'm working on a tool that would allow udev to name
ethernet devices in ascending embedded, slot 1 .. slot N order,
subsort by PCI bus/dev/fn breadth-first.  It'll be possible to use it
independent of udev as well for those distributions that don't use
udev in their installers.

Suggested fix #3: system board routing rules
One can constrain the system board layout to put NIC1 ahead of NIC2
regardless of breadth-first or depth-first discovery order.  This adds
a significant level of complexity to board routing, and may not be
possible in all instances (witness the above systems from several
major manufacturers).  I don't want to encourage this particular train
of thought too far, at the expense of not doing #1 or #2 above.


Feedback appreciated.  Patch tested on a Dell PowerEdge 1955 blade
with 2.6.18.

You'll also note I took some liberty and temporarily break the klist
abstraction to simplify and speed up the sort algorithm.  I think
that's both safe and appropriate in this instance.
Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

cpcihp_generic module requires configured "bridge" module parameter.
But it can be loaded successfully without that parameter.
Because module init call ends up returning positive value.

This patch prevents from loading without setting "bridge" module parameter.
Signed-off-by: NAkinbou Mita <akinobu.mita@gmail.com>
Signed-off-by: NScott Murray <scottm@somanetworks.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In order to finish converting to pci_get_* interfaces we need to add a couple
of bits of missing functionaility

pci_get_bus_and_slot() provides the equivalent to pci_find_slot()
(pci_get_slot is already taken as a name for something similar but not the
same)

pci_get_device_reverse() is the equivalent of pci_find_device_reverse but
refcounting
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>