From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B66FC433DF for ; Thu, 9 Jul 2020 14:48:47 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4F4DA20767 for ; Thu, 9 Jul 2020 14:48:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="GctB1BmC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4F4DA20767 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=hCtzqXyGRWfJLL4AfHJoe0X2LUNAN+5xzykOioTIolA=; b=GctB1BmCluhG9C7uPptJNzSNV jxwesdZ31mSgzS8T/cOGoA0mig3W1BoE8xWudYGUWfpMiuHq3oZFfWMD3gOdkd8TYY1fRJIct+1Ga hfdUPrB+l/OHE+N03rDehleBh8kgIUWOHQyWoVjEh4iFCv3WemEBNVhMu8uXWlmGTVcmwqUygEa0M j3VZ1An1CpTpzeb99Uv4DA//6/F6ZzGZsFJT2ZkaHHTuPCNOfTQDmyrukR5BkmmHLrqwKI5ReuQoO hfA6ygPFrSMjd5hw9p/PqCjEIdiGe+W+ZO86JEHolaXL8GWuIFt9Uj/VVsvKEJ0CTZJHhXXpOdQ0n Lv7oemvow==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jtXpS-0003je-Hk; Thu, 09 Jul 2020 14:47:14 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jtXpO-0003id-Li for linux-arm-kernel@lists.infradead.org; Thu, 09 Jul 2020 14:47:12 +0000 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 8DEC631B; Thu, 9 Jul 2020 07:47:09 -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 233F73F792; Thu, 9 Jul 2020 07:47:08 -0700 (PDT) Date: Thu, 9 Jul 2020 15:47:01 +0100 From: Lorenzo Pieralisi To: Pali =?iso-8859-1?Q?Roh=E1r?= Subject: Re: [PATCH v3] PCI: aardvark: Don't touch PCIe registers if no card connected Message-ID: <20200709144701.GA21760@e121166-lin.cambridge.arm.com> References: <20200528143141.29956-1-pali@kernel.org> <20200702083036.12230-1-pali@kernel.org> <20200709113509.GB19638@e121166-lin.cambridge.arm.com> <20200709122208.rmfeuu6zgbwh3fr5@pali> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200709122208.rmfeuu6zgbwh3fr5@pali> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200709_104710_812978_61C118BA X-CRM114-Status: GOOD ( 40.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tomasz Maciej Nowak , linux-pci@vger.kernel.org, Xogium , linux-kernel@vger.kernel.org, Marek =?iso-8859-1?Q?Beh=FAn?= , Remi Pommarel , Thomas Petazzoni , Bjorn Helgaas , linux-arm-kernel@lists.infradead.org, Andrew Murray Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jul 09, 2020 at 02:22:08PM +0200, Pali Roh=E1r wrote: > On Thursday 09 July 2020 12:35:09 Lorenzo Pieralisi wrote: > > On Thu, Jul 02, 2020 at 10:30:36AM +0200, Pali Roh=E1r wrote: > > > When there is no PCIe card connected and advk_pcie_rd_conf() or > > > advk_pcie_wr_conf() is called for PCI bus which doesn't belong to emu= lated > > > root bridge, the aardvark driver throws the following error message: > > > = > > > advk-pcie d0070000.pcie: config read/write timed out > > > = > > > Obviously accessing PCIe registers of disconnected card is not possib= le. > > > = > > > Extend check in advk_pcie_valid_device() function for validating > > > availability of PCIe bus. If PCIe link is down, then the device is ma= rked > > > as Not Found and the driver does not try to access these registers. > > > = > > > This is just an optimization to prevent accessing PCIe registers when= card > > > is disconnected. Trying to access PCIe registers of disconnected card= does > > > not cause any crash, kernel just needs to wait for a timeout. So if c= ard > > > disappear immediately after checking for PCIe link (before accessing = PCIe > > > registers), it does not cause any problems. > > > = > > > Signed-off-by: Pali Roh=E1r > > > = > > > --- > > > Changes in V3: > > > * Add comment to the code > > > Changes in V2: > > > * Update commit message, mention that this is optimization > > > --- > > > drivers/pci/controller/pci-aardvark.c | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > = > > > diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/cont= roller/pci-aardvark.c > > > index 90ff291c24f0..d18f389b36a1 100644 > > > --- a/drivers/pci/controller/pci-aardvark.c > > > +++ b/drivers/pci/controller/pci-aardvark.c > > > @@ -644,6 +644,13 @@ static bool advk_pcie_valid_device(struct advk_p= cie *pcie, struct pci_bus *bus, > > > if ((bus->number =3D=3D pcie->root_bus_nr) && PCI_SLOT(devfn) !=3D = 0) > > > return false; > > > = > > > + /* > > > + * If the link goes down after we check for link-up, nothing bad > > > + * happens but the config access times out. > > > + */ > > > + if (bus->number !=3D pcie->root_bus_nr && !advk_pcie_link_up(pcie)) > > > + return false; > > > + > > > return true; > > > } > > = > > Question: this basically means that you can only effectively enumerate > > bus number =3D=3D root_bus_nr and AFAICS if at probe the link did not > > come up it will never do, will it ? > > = > > Isn't this equivalent to limiting the bus numbers the bridge is capable > > of handling ? > > = > > Reworded: if in advk_pcie_setup_hw() the link does not come up, what's > > the point of trying to enumerate the bus hierarchy below the root bus ? > = > Hello Lorenzo! > = > PCIe link can theoretically come up even after boot, but aardvark driver > currently does not support link detection at runtime. So it checks and > enumerate device only at probe time. If the link is not up at probe enumerating devices below the root bus is basically useless and that's actually what is causing the delays you are fixing. Is this correct ? > I do not know if hardware has some mechanism to inform kernel that PCIe > link come up (or down) and re-enumeration is required. Or the only > option is polling via advk_pcie_link_up(). > = > So if device is not visible at the probe time then it would not appear > in system and cannot be used. This is current state. > = > Just to note that our hardware does not support physical hotplug of > mPCIe cards. You need to connect card when board is powered off. > = > So if at the aardvark probe time PCIe link is not up then trying to > enumerate devices under (software) root bridge is not needed. But it is > needed to register/enumerate software root bridge device and currently > both is done by one (recursive) call pci_host_probe(). I understand that but the bridge bus resource can be trimmed to just contain the root bus because that's the only one where there is a chance you can enumerate a device. I would like to get Bjorn's opinion on this, I don't like these "link is up" checks in config accessors (they are racy and honestly it is a run-time check that does not make much sense, either it is always true/false or it is inevitably racy) I was wondering if we can find an alternative solution but I am not sure the one I suggested above is better than this patch. Lorenzo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel