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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 F1B46C282CE for ; Wed, 22 May 2019 14:02:44 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 C738120675 for ; Wed, 22 May 2019 14:02:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rspueiNk"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="TiB5IfV+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C738120675 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.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=SPI/XFPHK+Q1slFad951UrnvRm6Kg2/AVymuV7HZY24=; b=rspueiNkryxYxe 10Y5FI4dSUUSyQr31wPz2O81bPbpt9VlOedeNsUknGzO/idywZqwlH8MeYgRp0FAUStUajOubfY22 sPqff8Mjo77Fm35MGEK6En4ngJg0lHWH5Whxm/zr8iJKHN4j05L4qGb9qjtoO2q9ShD5O+mbucKWc Q1KxfGD7VPJCj741vGfOz6gkP7uGuFaKgxEJ2dQEFuDjY5XW+LoqKTyoJcf0CC9msejWjW7v9+9dJ YB0+ZGvA6X/0bXAUEfetMPYj8Rlq9tdTkwSjqpbBusVXLxmk0SMwE3Ykf80FZmPixbTfbqzH7lGDI moFasBJSg/spZRWR2uYA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hTRpI-0005jt-Ip; Wed, 22 May 2019 14:02:40 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hTRpF-0005jM-If for linux-arm-kernel@lists.infradead.org; Wed, 22 May 2019 14:02:38 +0000 Received: from localhost (173-25-83-245.client.mchsi.com [173.25.83.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0C56320675; Wed, 22 May 2019 14:02:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558533757; bh=KTu3NjSg2iiGDgoB9aRWVmkH5c55r6B+TEQSSjSQf3U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TiB5IfV+S9KxIVjx6O4i4vgHsQOlh+RmPNLDUeSKScVe/Ik1n+H4rDSt4n0688O7h lNapBWDrWoQDfX/n8gtkEjdNgBr/q6eYeOZmzfMtERPy3LMVl33T2tZ5QrDXkTbzA0 iit2/21VJMjnlzoVA1c/tDP/mr6ZVU4mSkNK1WOQ= Date: Wed, 22 May 2019 09:02:36 -0500 From: Bjorn Helgaas To: Vidya Sagar Subject: Re: [PATCH V7 04/15] PCI: dwc: Move config space capability search API Message-ID: <20190522140235.GB79339@google.com> References: <20190517123846.3708-1-vidyas@nvidia.com> <20190517123846.3708-5-vidyas@nvidia.com> <20190521211757.GF57618@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190522_070237_647650_ADCEF0C5 X-CRM114-Status: GOOD ( 27.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, lorenzo.pieralisi@arm.com, mperttunen@nvidia.com, mmaddireddy@nvidia.com, linux-pci@vger.kernel.org, catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, robh+dt@kernel.org, kishon@ti.com, kthota@nvidia.com, thierry.reding@gmail.com, gustavo.pimentel@synopsys.com, jingoohan1@gmail.com, linux-tegra@vger.kernel.org, jonathanh@nvidia.com, linux-arm-kernel@lists.infradead.org, sagar.tv@gmail.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, May 22, 2019 at 02:26:08PM +0530, Vidya Sagar wrote: > On 5/22/2019 2:47 AM, Bjorn Helgaas wrote: > > On Fri, May 17, 2019 at 06:08:35PM +0530, Vidya Sagar wrote: > > > Move PCIe config space capability search API to common DesignWare file > > > as this can be used by both host and ep mode codes. > > > .../pci/controller/dwc/pcie-designware-ep.c | 37 +---------------- > > > drivers/pci/controller/dwc/pcie-designware.c | 40 +++++++++++++++++++ > > > drivers/pci/controller/dwc/pcie-designware.h | 2 + > > > 3 files changed, 44 insertions(+), 35 deletions(-) > > > --- a/drivers/pci/controller/dwc/pcie-designware.c > > > +++ b/drivers/pci/controller/dwc/pcie-designware.c > > > @@ -14,6 +14,46 @@ > > > #include "pcie-designware.h" > > > +/* > > > + * These APIs are different from standard pci_find_*capability() APIs in the > > > + * sense that former can only be used post device enumeration as they require > > > + * 'struct pci_dev *' pointer whereas these APIs require 'struct dw_pcie *' > > > + * pointer and can be used before link up also. > > > > I think this comment is slightly misleading because it suggests the > > reason we need these DW interfaces is because we're doing something > > before a pci_dev pointer is available. > > > > But these DW interfaces are used on devices that will *never* have a > > pci_dev pointer because they are not PCI devices. They're used on > > host controller devices, which have a PCIe link on the downstream > > side, but the host controller driver operates them using their > > upstream, non-PCI interfaces. Logically, I think they would be > > considered parts of Root Complexes, not Root Ports. > > > > There's actually no reason why that upstream interface should look > > anything like PCI; it doesn't need to organize registers into > > capability lists at all. It might be convenient for the hardware to > > do that and share things with a Root Port device, which *is* a PCI > > device, but it's not required. > > > > It also really has nothing to do with whether the link is up. This > > code operates on hardware that is upstream from the link, so we can > > reach it regardless of the link. > > I added this comment after receiving a review comment to justify why > standard pci_find_*capability() APIs can't be used here. Hence added > this. I understand your comment that DW interface need not have to > be a PCI device, but what is present in the hardware is effectively > a root port implementation and post enumeration, we get a 'struct > pci_dev' created for it, hence I thought it is fine to bring 'struct > pci_dev' into picture. This code operates on the host controller. It configures the bridge that leads *to* PCI devices. Since that bridge is not a PCI device, the PCI specs don't say anything about how to program it. The fact that the host controller programming interface happens to resemble the PCI programming interface is purely coincidental. > Also, I agree that mention of 'link up' is unwarranted and could be > reworded in a better way. > > Do you suggest to remove this comment altogether or reword it s/and > can be used before link up also/and can be used before 'struct > pci_dev' is available/ ? Maybe something like this? These interfaces resemble the pci_find_*capability() interfaces, but these are for configuring host controllers, which are bridges *to* PCI devices but are not PCI devices themselves. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel