On Tue, Jul 10, 2012 at 3:56 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: > On Sat, Jun 23, 2012 at 1:42 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: >> If surprise removal is not supported, that event get dropped later. >> So there is no point to enable that. >> >> Also some sick chipset have those bit flip around when the card is not present. >> and make log full of useless warning. > > HP_SUPR_RM tests the Slot Capabilities "Hot-Plug Surprise" bit, which > indicates that an adapter might be *removed* without prior > notification (sec 7.8.9). > > PCI_EXP_SLTCTL_PDCE is the Slot Control "Presence Detect Changed > Enable" bit, which enables interrupts for any change in the Slot > Status "Presence Detect State", i.e., we may get interrupts for either > add or remove events. > > In interrupt_event_handler(), we drop both add and remove events if > !HP_SUPR_RM(). Specifically, we drop *add* events if surprise > *removal* isn't supported. That seems strange -- just from reading > the spec, it seems that a surprise *add* could occur even if the > "Hot-Plug Surprise" bit is not set. Interesting, that means after card is plugged in, we don't need to press attention button to bring it online. And other oses like windows and solaris do need to press the button like current linux doing. > > So I'm not convinced that we should even bother looking at the > "Hot-Plug Surprise" bit... Maybe we'd be better off if we just > removed that HP_SUPR_RM() test in interrupt_event_handler() and always > called handle_surprise_event(). Ah, that means some system with chip problem will keep feeding pciehp_wq with pciehp_disable_slot and pciehp_enable_slot. Anyway please drop this patch now. Thanks Yinghai -- 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
