On Wed, Jul 11, 2012 at 11:58 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > On Wed, Jul 11, 2012 at 9:21 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> On Tue, Jul 10, 2012 at 04:56:15PM -0600, Bjorn Helgaas wrote: >> >> What bad things would happen if we did the following? >> >> I have no way to test this, but I don't understand what benefit >> there is in testing HP_SUPR_RM() here. >> >> diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c >> index 27f4429..4bbe257 100644 >> --- a/drivers/pci/hotplug/pciehp_ctrl.c >> +++ b/drivers/pci/hotplug/pciehp_ctrl.c >> @@ -463,9 +463,8 @@ static void interrupt_event_handler(struct work_struct *work) >> break; >> case INT_PRESENCE_ON: >> case INT_PRESENCE_OFF: >> - if (!HP_SUPR_RM(ctrl)) >> - break; >> - ctrl_dbg(ctrl, "Surprise Removal\n"); >> + ctrl_dbg(ctrl, "Presence Detect changed (now %spresent)\n", >> + info->event_type == INT_PRESENCE_OFF ? "not " : ""); >> handle_surprise_event(p_slot); >> break; >> default: > > some chipsets (from cpu vendor) have some problem, when you remove the > card, the present bit > will keep flip around. > Because that present bit is "OR" with inband (pcie link) and outband > (input from VPP) detection. > and silicon is trying to retrain the link to see if there is any device there. > That means handle_surprise_event would get called frequently. What's the connection with HP_SUPR_RM()? Is it just a coincidence that chipsets that set the "Hot-Plug Surprise" bit don't have this problem with the Presence Detect State bit? Using HP_SUPR_RM() seems like a totally bogus way to work around a presence detect issue. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
