core/pcie-slot: Better explain suprise_check
Working out what was actually going on here took forever.
@@ -215,24 +215,19 @@ static int64_t pcie_slot_set_power_state_ext(struct pci_slot *slot, uint8_t val,
return OPAL_SUCCESS;
}
- /* The power supply to the slot should be always on when surprise
- * hotplug is claimed. For this case, update with the requested
- * power state and bail immediately.
+ /*
+ * Suprise hotpluggable slots need to be handled with care since
+ * many systems do not implement the presence detect side-band
+ * signal. Instead, they rely on in-band presence to report the
+ * existence of a hotplugged card.
*
- * The PCIe link is likely down if we're powering on the slot upon
- * the detected presence. Nothing behind the slot will be probed if
- * we do it immediately even we do have PCI devices connected to the
- * slot. For this case, we force upper layer to wait for the PCIe
- * link to be up before probing the PCI devices behind the slot. It's
- * only concerned in surprise hotplug path. In managed hot-add path,
- * the PCIe link should have been ready before we power on the slot.
- * However, it's not harmful to do so in managed hot-add path.
+ * This is problematic because:
+ * a) When PERST is asserted in-band presence doesn't work, and
+ * b) Switches assert PERST as a part of the "slot power down" sequence
*
- * When flag PCI_SLOT_FLAG_FORCE_POWERON is set for the PCI slot, we
- * should turn on the slot's power supply on hardware on user's request
- * because that might have been lost. Otherwise, the PCIe link behind
- * the slot won't become ready for ever and PCI adapter behind the slot
- * can't be probed successfully.
+ * To work around the problem we leave the slot physically powered on
+ * and exit early here. This way when a new card is inserted, the switch
+ * will raise an interrupt due to the PresDet status changing.
*/
if (surprise_check && slot->surprise_pluggable) {
slot->power_state = val;
