Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3929425pxu; Tue, 20 Oct 2020 04:25:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwN2QAKoJ9h0n2ulGWr5eeBqq8MFDCYhC4xwsxhnMp1ZklvElPqX7tDmDsrw3ZMZrPLebrP X-Received: by 2002:a17:906:a195:: with SMTP id s21mr2535076ejy.146.1603193107850; Tue, 20 Oct 2020 04:25:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603193107; cv=none; d=google.com; s=arc-20160816; b=BNGjKxrCpFctFw4JKT1mri4ZgZbIW/Qy7PkKWJ9QljPSZHeWTH+K0QUx3EpPLYNj36 raUi8WlnViYC/JYY/bnlclJkC+hkVisbQc1mQhnU6p9S0vf9S4Ctlaw8YdlEK72ZsEqI yqDnoH2dslKeQ7bcLJo/kCl95ZKZcyrhUSXMFPRJ0ToGf5mVyxqIckvd1xjlYjrKcNsZ f2h7uOZROX5fIJsRLiRlEWOKmGVvmNofSGagA5wDhCcuQYD0c3ut/KLnf33zOmccs4fG R9c8QeTizNW2VsWozRuierYNnL80Vlnhd8DfGIrybjnNAdXq5n77gDsVbiKx8BNWPtLp +TCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=+b4FhzRDuyiX44Xt/CojMeApw69GKqI81Ebex5Zz5W4=; b=CmZwya7s1cR88+c3UxrF/YwVMvDBR7wLiBX+6CBsqWM/X42lklecnFSjcHBKPoHyyK NE3iCxOfWQO0QaG6Yyd7EXX/N2ZtuTIqkK6T1bpFL7r4J2Rf2qKDfhMLefuJbLe6UDzT lmzx5tyVrzBr4xQDZOLsua2VYjI/5U/N0vVDHc2Pug1DAxIFQfSduT5aK+nWXqKLKj+D iSdncXz46bJGChOGryuHM6GR6SlC6Ctru4k1Adh3j1bFXU2MmveMHICMKglQzVBX/uZi F1yEYG1GGV7QCZyVrYqJhIEzKj2sMiY1OegMB7H7faxAOGbKacEcDaB829JZZyUhq83t UolA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bz16si1001858ejc.508.2020.10.20.04.24.45; Tue, 20 Oct 2020 04:25:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404052AbgJTJsq (ORCPT + 99 others); Tue, 20 Oct 2020 05:48:46 -0400 Received: from foss.arm.com ([217.140.110.172]:48786 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404045AbgJTJsq (ORCPT ); Tue, 20 Oct 2020 05:48:46 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 231BF101E; Tue, 20 Oct 2020 02:48:46 -0700 (PDT) Received: from e121166-lin.cambridge.arm.com (e121166-lin.cambridge.arm.com [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DDB713F66E; Tue, 20 Oct 2020 02:48:44 -0700 (PDT) Date: Tue, 20 Oct 2020 10:48:39 +0100 From: Lorenzo Pieralisi To: Rob Herring Cc: "Z.q. Hou" , "linux-kernel@vger.kernel.org" , PCI , Bjorn Helgaas , Gustavo Pimentel , Michael Walle , Ard Biesheuvel Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops Message-ID: <20201020094839.GA21935@e121166-lin.cambridge.arm.com> References: <20200916054130.8685-1-Zhiqiang.Hou@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 18, 2020 at 09:27:40AM -0600, Rob Herring wrote: [...] > > > Maybe a link down just never happens once up, but if so, then we only need > > > to check it once and fail probe. > > > > Many customers connect the FPGA Endpoint, which may establish PCIe link > > after the PCIe enumeration and then rescan the PCIe bus, so I think it should > > not exit the probe of root port even if there is not link up during enumeration. > > That's a good reason. I want to unify the behavior here as it varies > per platform currently and wasn't sure which way to go. We don't need to fail probe - just skip enumeration. Is there an IRQ event associated with link coming up ? Scanning the bus can be done upon link-up IRQ. For platforms that forward the link down as an SError this still does not solve the problem (if the link goes down unexpectedly) but I question their design in the first place, this patch does not fix their behaviour regardless. Lorenzo