powerpc/PCI hotplug: fix hotplug slot registration for populated busses

f46753c5e354b857b20ab8e0fe7b2579831dc369 separated slot registration
into 2 steps: pci_create_slot() to register slots and make available
interfaces in /sys/bus/pci/slots that weren't necessarily related to
hotplug, then a separate step where a hotplug module could associate
enable/release/etc functionality with an existing slot.

To allow existing hotplug registration code to continue functioning
in a future world where a slot may have already previously been
registered via pci_create_slot(), rpaphp_register_slot() was
modified to extract the corresponding slotno from the device_node
associated with it via PCI_SLOT(PCI_DN(slot->dn->child)->devfn) so
pci_hp_register could locate a pre-existing pci_slot structure if
present.

However, in rpaphp_add_slot(), slot->dn is assigned the device_node
corresponding to the pci bus, and this is true for each hotplug slot
we try to register for that bus. Thus,
PCI_SLOT(PCI_DN(slot->dn->child)->devfn) always corresponds to
Slot 0, so for any cases where a device is present on the bus prior
to loading the rpaphp module, slot registration fails for all slots
past Slot 0.

This likely didn't get noticed due to pSeries PCI expansion devices
generally dedicating a PHB for every hotpluggable slot. However, the
original code in rpaphp_add_slot was written to allow hardware to
configure the number of hotplug slots via ibm,drc-indexes FDT values.

Since we still don't make use of the 2-step slot registration and
rely on pci_hp_register for both slot and hotplug registration, and
since none of the rpaphp hotplug operations rely on slot->number,
we could simply revert to leaving slot->number uninitialized. But
to still allow for us to adopt the 2-step registration and
associate hotplug registration with an existing slot in the future,
fix this by assigning slotnr's sequentially for each hotplug slot
specified in the drc-indexes FDT entry.

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
powerpc/eeh: fix duplicate eeh sysfs entry creation when eeh is disabled

6a040ce72598159a74969a2d01ab0ba5ee6536b3 moved the creation of
eeh-related sysfs entries out of eeh_add_device_late so that code
that associated eeh_dev's with pci_dev's could be done ahead of
pci_bus_add_devices(), while the sysfs entry creation could be
deferred until after the devices were fully added along with the
rest of their associated sysfs hierachy/entries.

However, in the case of eeh_subsystem_enabled == false, we used
to skip both eeh_add_device_late() code to associate eeh_dev's
with pci_dev's, *and* the creation of eeh sysfs entries. Now we
skip the former, but still attempt the latter via
eeh_sysfs_add_device.

eeh_sysfs_add_device does set an EEH_DEV_SYSFS flag in the
associated eeh_dev structure to avoid creating duplicate entries
in subsequent calls to pcibios_add_pci_devices(). However, in
the case of eeh_subsystem_enabled == false, this gets skipped
due to eeh_dev being NULL as a result of eeh_add_device_late()
having been skipped.

Fix this by re-introducing the if (!eeh_subsystem_enabled) return;
statement that previously guarded eeh sysfs entry creation.

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>