On Tue, 2013-11-26 at 15:26 -0700, Bjorn Helgaas wrote: > [+cc Alex] > > On Tue, Nov 26, 2013 at 3:06 PM, Rajat Jain <rajatjain@xxxxxxxxxxx> wrote: > >> From: Bjorn Helgaas [mailto:bhelgaas@xxxxxxxxxx] > >> > Currently in my patch, the pciehp_use_link_events=1 is used to only > >> enable link state change notifications, but in case pcie_isr() finds > >> "DLL changed" bit set in "Slot status", it processes the link state > >> change. I'll make the single line change to pcie_isr() to process the > >> event only if pciehp_use_link_events=1. Let me know if this sounds > >> alright. > >> > >> If we can avoid it, I'd prefer not to add the "pciehp_use_link_events" > >> module parameter. What would break if we just *always* used link > >> events? > > > > Not really "break", but I'd think some changes in behavior shall be visible: > > > > 1) When a card is pulled out (thus causing the link to go down), it shall always be disabled - whether or not it supports "surprise removal" (in the capabilities). I think this would be the right thing to do in this situation. > > Yep, this sounds like it would be OK. > > > 2) Even other scenarios where the link may go down - e.g. device reset using an external reset pin, or a firmware initiated reset etc, shall cause the device to be immediately removed and re-added again when the link comes back up). This may also be desired. > > This sounds OK, too. There's already some fancy dancing for similar > scenarios in pciehp_reset_slot(); maybe that would have to be > extended. Alex might have input here. So long as reset initiated through pci-core doesn't cause a hotplug I think I'm ok with it. I saw code was already being added around slot reset to mask link changes, just like we do with presence detection. Thanks, Alex > > 3) If the link comes up automatically as soon as a card is plugged in (i.e. without the need to turn on power or do anything else from SW), the card shall be immediately added - even if surprise capability is not present. I'm not sure if this is desired. That's because the current behavior is that for slots that do not support surprise events, the user has to initiate the hot-add using the attention button. Even after that, he gets a 5 second time to cancel the operation in case he wishes. This will no longer be the case, if use of link events is always enabled. > > This one sounds like a problem. But I think we could manage this, > e.g., by noticing the link-up interrupt, but waiting for the 5-second > timeout if an attention button is present. > > > I think it would be fair to say that if use of link events is always supported, it would be roughly equivalent to a slot supporting surprise events. (Surprise events work on "presence detect" pin, and this will work on the link state changes). > > > > Thanks, > > > > Rajat > > -- 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
