Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1040386pxb; Tue, 8 Feb 2022 08:01:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJw8CXOXThz92s4dflPaFh3gus7CQ6Btmf+VQzsZ0/ZTJBL2TtuIBcimD0QS8tErxy8um54e X-Received: by 2002:a05:6402:27d0:: with SMTP id c16mr1053738ede.276.1644336109144; Tue, 08 Feb 2022 08:01:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644336109; cv=none; d=google.com; s=arc-20160816; b=KNGnozG3tYTA5RKmLFjnUHTlwUwkcCEDLIOCW6ICJGdT30cOjCIIP/5HZ7JtvV49BR yZ9iCKX9SdfhLwUcMd73Mhrf5WR1X8e2AOCAK2tkZRD+gp16CHGDEW1aPzuuSo+uIs3E 05BD3ikdaQXFyPRjIWTpfN1TzoVwWCR3E/QS16xFxMIC8qF4JjaZhfyvmm2Cihs994xT viuR3liyVssu4IXVnxehPDgBfCES5OBroZUhtElaCHAu790iRB6W2qq/2hV0Y3/Kmv34 qoJQCjll0Fgru4XmqD+awpaZLdGlJtm9FZEQ210eD6WjcO8xxvuaNJVRzMStsnhgu4iA 42AQ== 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=rpIaK/SE5YaAF2ICuE7L1kLLDXV8lXDjM6EOeLHptAg=; b=Xz1M4vfP8lcaFIkrVVDpbIzyVVj0VF2zTBHQyu187RlEVIItbk/xZnQbtA6mQrTzLp AQ5zLNSKfNNtKeiFYM2N3uO7ZrF21dTI5S8JX058k8mfCJ11H4eQPT1edeCXt/5X4mvW uAzMxgM//twQXiwB+7xwoQ6arP+ALuJN5kMS4N27I1LgmxB/IAXOpcnZ0cJ5kDKc1PwY o7I05bOzzjhUwKFc5ZGdXHn5wjDZGU02/9BxbunagFVwSFE/BK4Nv1op8Nj1wuMkbCcN MhC54JyO53KLo5S9b995ygGPlxiDIO+/troMum0HQJHn+wbMAAnTJWwv60wx9PT5bfww uZKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g2si10078092ejt.974.2022.02.08.08.01.23; Tue, 08 Feb 2022 08:01:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S1347472AbiBHLxu (ORCPT + 99 others); Tue, 8 Feb 2022 06:53:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43962 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239521AbiBHLxt (ORCPT ); Tue, 8 Feb 2022 06:53:49 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9A1F2C03FEC0; Tue, 8 Feb 2022 03:53:48 -0800 (PST) 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 43C17ED1; Tue, 8 Feb 2022 03:53:48 -0800 (PST) Received: from lpieralisi (e121166-lin.cambridge.arm.com [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 405EF3F70D; Tue, 8 Feb 2022 03:53:47 -0800 (PST) Date: Tue, 8 Feb 2022 11:53:44 +0000 From: Lorenzo Pieralisi To: Kishon Vijay Abraham I , bhelgaas@google.com Cc: Rob Herring , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v2 4/5] PCI: keystone: Add quirk to mark AM654 RC BAR flag as IORESOURCE_UNSET Message-ID: <20220208115344.GB6233@lpieralisi> References: <20211126083119.16570-1-kishon@ti.com> <20211126083119.16570-5-kishon@ti.com> <20220104155741.GA28358@lpieralisi> 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) X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 04, 2022 at 08:38:46PM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On 11/01/22 11:53 am, Kishon Vijay Abraham I wrote: > > Hi Lorenzo, > > > > On 04/01/22 9:27 pm, Lorenzo Pieralisi wrote: > >> On Fri, Nov 26, 2021 at 02:01:18PM +0530, Kishon Vijay Abraham I wrote: > >>> AM654 RootComplex has a hard coded 64 bit BAR of size 1MB and also has > >>> both MSI and MSI-X capability in it's config space. If PCIEPORTBUS is > >>> enabled, it tries to configure MSI-X and msix_mask_all() adds about 10 > >>> Second boot up delay when it tries to write to undefined location. > >>> > >>> Add quirk to mark AM654 RC BAR flag as IORESOURCE_UNSET so that > >>> msix_map_region() returns NULL for Root Complex and avoid un-desirable > >>> writes to MSI-X table. > >> > >> I don't think this is the right fix (it is not even a fix, just a > >> plaster to workaround an issue). > >> > >> What do you mean by "writing to an undefined location" ? > >> > >> What does "a hard coded BAR" mean ? > >> > >> What happens if we _rightly_ write into it (ie to size it) ? > > > > There are two parts w.r.t setting the BAR; one is during the configuration and > > the other is during the enumeration. > > i) During the configuration, the size of the BAR is configured and the inbound > > ATU is configured to map the BAR to a physical memory. > > ii) During the enumeration, the size of the BAR is obtained and an address is > > allocated and programmed in the BAR. > > > > In the case of RC, for (i) above, the BAR size is configured as '0' > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-designware-host.c#n556 > > and the inbound ATU is not programmed at all. > > > > However, in the case of AM654, the HW configures BAR0 for a fixed size of 1MB > > (irrespective of what SW programmed in [i]). While this was done more for a > > endpoint usecase, since the same IP is configured for both RC mode and EP mode, > > the fixed BAR size is seen with RC mode as well. AM654 also has MSI-X capability > > for RC mode (the IP should have been ideally configured to have MSI-X capability > > for EP mode). This results in PCIEPORTBUS doing some undesired access in > > msix_mask_all(). > > > > Here I configure IORESOURCE_UNSET so that memory is not allocated for RC BAR. > > Do you need further clarifications on this? There are two things here: 1) As Rob mentioned, you can write it as a quirk applying only to the bridge _only_ 2) What you want is that the BAR should not be visible to the OS since it is not an actual resource. What I am questioning is whether your way of doing that complies with how this is done in the kernel for other devices/bridges. I need Bjorn's input on this since he knows better (especially wrt IORESOURCE_UNSET usage). I don't want to add any other IORESOURCE_UNSET usage that deviates from what's expected from it Lorenzo > > > >> > >> Lorenzo > >> > >>> Signed-off-by: Kishon Vijay Abraham I > >>> --- > >>> drivers/pci/controller/dwc/pci-keystone.c | 8 +++++++- > >>> 1 file changed, 7 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c > >>> index 52d20fe17ee9..73e6626a0d8f 100644 > >>> --- a/drivers/pci/controller/dwc/pci-keystone.c > >>> +++ b/drivers/pci/controller/dwc/pci-keystone.c > >>> @@ -557,8 +557,14 @@ static void ks_pcie_quirk(struct pci_dev *dev) > >>> { 0, }, > >>> }; > >>> > >>> - if (pci_is_root_bus(bus)) > >>> + if (pci_is_root_bus(bus)) { > >>> bridge = dev; > >>> + if (pci_match_id(am6_pci_devids, bridge)) { > >>> + struct resource *r = &dev->resource[0]; > >>> + > >>> + r->flags |= IORESOURCE_UNSET; > >>> + } > >>> + } > >>> > >>> /* look for the host bridge */ > >>> while (!pci_is_root_bus(bus)) { > >>> -- > >>> 2.17.1 > >>>