Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp839351ybl; Thu, 22 Aug 2019 05:48:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqzeCUETiUmTNAWhbaMb0PDRJCWIYpLTa6OWozKEgrFPSl9orrR0HZy54C4D9Aw5fbHZDO+q X-Received: by 2002:a62:dbc6:: with SMTP id f189mr12107161pfg.237.1566478115714; Thu, 22 Aug 2019 05:48:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566478115; cv=none; d=google.com; s=arc-20160816; b=jNip1YzIs3oQISAWmNly0iEaVmyzv42WMa8zeUrZUJFn8Ghlz4WtX5Bb69NCTxqz4J INcpSBhy6RrG08Wc4wJWTThWJRy43foEHAsd5GNFuNaaa4FcxPqLuiFD5dwxriZHLsWy /e8979aoG4gMzxivyrYs27fXbiZA6v1tdekWDiKT9dxAvcoxIVSBaQZXAczSLNvF+73h 3u2psHtLnK29z7SVCdFlBFCxCiBIz/XL6VLn6g0rYQbC2RqM/VSJeIX4tZHrJX0OFOVZ xNOVFRxgkxnqLOPR7zgaT/49E/M94UJQKXPlsB+NWG6lQ1kAjdmyzPfkLN7jXH1xpWlI g4jw== 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; bh=8SSwx1vT0y20HN6TpWXR8FV0I0WMl9TTZGMbrSuhww8=; b=k5ao/HaqDrhYTqXQbvCGN5s/CmXQKd7ggs3pck1y6deGDMZ1W0SXBV9taK9xKzGFrO ObjS7ILkWvNzI7cNunPA6I4AEj61nobKbc49nN/r8zgI9/eCfVWyifv/5sO3l6DiDlFO YzRT4LDXRhbSoUvmpfkVJbmd1XCJuk+CF0fl62pPNyOGNnQchpBRuB1qCBLHDTHN9KBV 3/ISNVI1m4Xula9mz7MjXVSWLB3JPR27qmIG6ofE5dKR25uhSnxJtxVM7EE6Q/t8xRrZ LNQqr2jQU81Fu/UdWkERczvqEyDwEJQrp7D+fCfKDBK1v7TWW5np86g0lSPFxic2ndV9 ly0w== 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 d7si160901pjw.103.2019.08.22.05.48.21; Thu, 22 Aug 2019 05:48:35 -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 S1732699AbfHVLNT (ORCPT + 99 others); Thu, 22 Aug 2019 07:13:19 -0400 Received: from foss.arm.com ([217.140.110.172]:44100 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728594AbfHVLNT (ORCPT ); Thu, 22 Aug 2019 07:13:19 -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 811CF344; Thu, 22 Aug 2019 04:13:18 -0700 (PDT) Received: from localhost (unknown [10.37.6.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CFA4E3F246; Thu, 22 Aug 2019 04:13:17 -0700 (PDT) Date: Thu, 22 Aug 2019 12:13:16 +0100 From: Andrew Murray To: Jonathan Chocron Cc: lorenzo.pieralisi@arm.com, bhelgaas@google.com, jingoohan1@gmail.com, gustavo.pimentel@synopsys.com, robh+dt@kernel.org, mark.rutland@arm.com, dwmw@amazon.co.uk, benh@kernel.crashing.org, alisaidi@amazon.com, ronenk@amazon.com, barakw@amazon.com, talel@amazon.com, hanochu@amazon.com, hhhawa@amazon.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v4 7/7] PCI: dwc: Add validation that PCIe core is set to correct mode Message-ID: <20190822111315.GN23903@e119886-lin.cambridge.arm.com> References: <20190821153545.17635-1-jonnyc@amazon.com> <20190821154745.31834-3-jonnyc@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190821154745.31834-3-jonnyc@amazon.com> User-Agent: Mutt/1.10.1+81 (426a6c1) (2018-08-26) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 21, 2019 at 06:47:45PM +0300, Jonathan Chocron wrote: > Some PCIe controllers can be set to either Host or EP according to some > early boot FW. To make sure there is no discrepancy (e.g. FW configured > the port to EP mode while the DT specifies it as a host bridge or vice > versa), a check has been added for each mode. > > Signed-off-by: Jonathan Chocron > Acked-by: Gustavo Pimentel > --- > drivers/pci/controller/dwc/pcie-designware-ep.c | 8 ++++++++ > drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++++++ > 2 files changed, 16 insertions(+) > > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c > index 2bf5a35c0570..00e59a134b93 100644 > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c > @@ -531,6 +531,7 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep) > int ret; > u32 reg; > void *addr; > + u8 hdr_type; > unsigned int nbars; > unsigned int offset; > struct pci_epc *epc; > @@ -543,6 +544,13 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep) > return -EINVAL; > } > > + hdr_type = dw_pcie_readb_dbi(pci, PCI_HEADER_TYPE); > + if (hdr_type != PCI_HEADER_TYPE_NORMAL) { > + dev_err(pci->dev, "PCIe controller is not set to EP mode (hdr_type:0x%x)!\n", > + hdr_type); > + return -EIO; > + } > + > ret = of_property_read_u32(np, "num-ib-windows", &ep->num_ib_windows); > if (ret < 0) { > dev_err(dev, "Unable to read *num-ib-windows* property\n"); > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c > index f93252d0da5b..d2ca748e4c85 100644 > --- a/drivers/pci/controller/dwc/pcie-designware-host.c > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c > @@ -323,6 +323,7 @@ int dw_pcie_host_init(struct pcie_port *pp) > struct pci_bus *child; > struct pci_host_bridge *bridge; > struct resource *cfg_res; > + u8 hdr_type; > int ret; > > raw_spin_lock_init(&pci->pp.lock); > @@ -396,6 +397,13 @@ int dw_pcie_host_init(struct pcie_port *pp) > } > } > > + hdr_type = dw_pcie_readb_dbi(pci, PCI_HEADER_TYPE); Do we know if it's always safe to read these registers at this point in time? Later in dw_pcie_host_init we call pp->ops->host_init - looking at the implementations of .host_init I can see: - resets being performed (qcom_ep_reset_assert, artpec6_pcie_assert_core_reset, imx6_pcie_assert_core_reset) - changes to config space registers (ks_pcie_init_id, dw_pcie_setup_rc) including setting PCI_CLASS_DEVICE - and clocks being enabled (qcom_pcie_init_1_0_0) I'm not sure if your changes would cause anything to break for these other controllers (or future controllers) as I couldn't see any other reads to the config. Given that we are reading config space should dw_pcie_rd_own_conf be used? (For example kirin_pcie_rd_own_conf does something special). Thanks, Andrew Murray > + if (hdr_type != PCI_HEADER_TYPE_BRIDGE) { > + dev_err(pci->dev, "PCIe controller is not set to bridge type (hdr_type: 0x%x)!\n", > + hdr_type); > + return -EIO; > + } > + > pp->mem_base = pp->mem->start; > > if (!pp->va_cfg0_base) { > -- > 2.17.1 >