Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3135163imm; Sun, 29 Jul 2018 11:03:33 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfaXsacPuiL7znJjKGmD55KRHRe0t3N93IYTMKAsg2g58YcMPB2zEXBmAV2nZmiQe7CVc5V X-Received: by 2002:a17:902:5501:: with SMTP id f1-v6mr13657711pli.219.1532887413905; Sun, 29 Jul 2018 11:03:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532887413; cv=none; d=google.com; s=arc-20160816; b=wHfJMMpS+hk7DsUTaJl21Mncud6+1yIU/90WKhN2IGbESBsqPokx9zWZeZOT53cqEO DAd3VcBXBTKVvk9b44bqUpbZOwK4bhXqb+21i4Dq4/tZNfEa2LEAAlnST+vi9rdN8uo3 CgDsryLLt2A1y6Fzb7lUqPzPu/p4DelmH7Anwf0E7LN9zJQ0/pJRIxCBQc4CrxO4Ob/6 +1UkIXpjda4EnXre28YQrfrHQYuRo1GtuagbX8qULvL2QwyYXy/4PztmDc81MyQ8upx8 Bg6GmayJB/5kNLECPR986GtjYlrswClT61S9+Vk41aWJ00ElaDNXDJ/VS5B0DQ3aOQO0 KjQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=989XdAPKuID3HyQUaW9Fg0vPQ+0jrufOXyxc61+07i4=; b=o77bFibJOS2WgSekDvRebzmDf2kbEKAcnuVJksQ/EMgm03JgnWmoiFsSD2Jq++Ttri 9q3AIfo4dOoa9LwfIR47/wK3CkqMJ/991RAn+MrQi/R3sgnImjzAkmolz+IIUYkOCMQH LHafZoNjo8iJHhgzQSDJmEnci48tbTTUEAdoCx5CLXXmQXvdsJjfOtV64N1URInqKAWu mAYYdF8xbQXN1N92Eyo/qMW9LoOb7mTNt4Qa/QRcMV6sIheZ4qdTLqBQ4I6q5/weHwZG 2btSHEg/n4PERteW1U+JMM799gS+liDYKn21aFgiBKQ3j6eb6tHfmk1uA1aa8EGaLmKz 4/hw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n184-v6si8938485pga.98.2018.07.29.11.03.19; Sun, 29 Jul 2018 11:03:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726813AbeG2Tds (ORCPT + 99 others); Sun, 29 Jul 2018 15:33:48 -0400 Received: from bmailout2.hostsharing.net ([83.223.90.240]:41819 "EHLO bmailout2.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726417AbeG2Tds (ORCPT ); Sun, 29 Jul 2018 15:33:48 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id 241CE2800B3DC; Sun, 29 Jul 2018 20:02:31 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id C08E37DDE8; Sun, 29 Jul 2018 20:02:30 +0200 (CEST) Date: Sun, 29 Jul 2018 20:02:30 +0200 From: Lukas Wunner To: Sinan Kaya Cc: Bjorn Helgaas , Oza Pawandeep , linux-pci@vger.kernel.org, open list , Keith Busch , linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset Message-ID: <20180729180230.GA11016@wunner.de> References: <12fc8de5-ff03-cb00-52cb-25a43c71d03a@codeaurora.org> <20180708171418.GA11476@wunner.de> <20180709160008.GA1490@wunner.de> <20180720200123.GS128988@bhelgaas-glaptop.roam.corp.google.com> <2febe688-f973-5ff5-f61d-0451ad7d36ae@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2febe688-f973-5ff5-f61d-0451ad7d36ae@kernel.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 20, 2018 at 07:58:20PM -0700, Sinan Kaya wrote: > My patch solves the problem if AER interrupt happens before the hotplug > interrupt. We are masking the data link layer active interrupt. So, > AER/DPC can perform their link operations without hotplug driver race. > > We need to figure out how to gracefully return inside hotplug driver > if link down happened and there is an error pending. > > My first question is why hotplug driver is reacting to the link event > if there was not an actual device insertion/removal. > > Would it help to keep track of presence changed interrupts since last > link event? > > IF counter is 0 and device is present, hotplug driver bails out > silently as an example. Counting PDC events doesn't work reliably if multiple such events occur in very short succession as the interrupt handler may not run quickly enough. See this commit message which shows unbalanced Link Up / Link Down events: https://patchwork.ozlabs.org/patch/867418/ And on Thunderbolt, interrupts can be signaled even though the port and its parents are in D3hot (sic!). A Thunderbolt daisy chain can consist of up to 6 devices, each comprising a PCI switch, so there's a cascade of over a dozen Upstream / Downstream ports between the Root port and the hotplug port at the end of the daisy chain. God knows how many events have occurred by the time all the parents are resumed to D0 and the Slot Status register of the hotplug port is read/written. That was really the motivation for the event handling rework. Thanks, Lukas