@@ -2931,30 +2931,20 @@ static int64_t phb4_hreset(struct pci_slot *slot)
static int64_t phb4_freset(struct pci_slot *slot)
{
struct phb4 *p = phb_to_phb4(slot->phb);
- uint8_t presence = 1;
uint64_t reg;
uint16_t reg16;
switch(slot->state) {
case PHB4_SLOT_NORMAL:
+ case PHB4_SLOT_FRESET_START:
PHBDBG(p, "FRESET: Starts\n");
/* Reset max link speed for training */
p->max_link_speed = phb4_get_max_link_speed(p, NULL);
- /* Nothing to do without adapter connected */
- if (slot->ops.get_presence_state)
- slot->ops.get_presence_state(slot, &presence);
- if (!presence) {
- PHBDBG(p, "FRESET: No device\n");
- return OPAL_SUCCESS;
- }
-
PHBDBG(p, "FRESET: Prepare for link down\n");
-
phb4_prepare_link_change(slot, false);
- /* fall through */
- case PHB4_SLOT_FRESET_START:
+
phb4_pcicfg_read16(&p->phb, 0, p->ecap + PCICAP_EXP_LCTL,
®16);
reg16 |= PCICAP_EXP_LCTL_LINK_DIS;
When we do an freset the first step is to check if a card is present in the slot. However, this only occurs when we enter phb4_freset() with the slot state set to SLOT_NORMAL. This occurs in: a) The creset path, and b) When the OS manually requests an FRESET via an OPAL call. a) is problematic because in the boot path the generic code will put the slot into FRESET_START manually before calling into phb4_freset(). This can result in a situation where a device is detected on boot, but not after a CRESET. I've noticed this occurring on systems where the PHB's slot presence detect signal is not wired to an adapter. In this situation we can rely on the in-band presence mechanism, but the presence check will make us exit before that has a chance to work. Additionally, if we enter from the CRESET path this early exit leaves the slot's PERST signal being left asserted. This isn't currently an issue, but if we want to support hotplug of devices into the root port it will be. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> --- hw/phb4.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-)