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=-16.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 CD4CEC4338F for ; Mon, 9 Aug 2021 16:03:57 +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 621BA60EE7 for ; Mon, 9 Aug 2021 16:03:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 621BA60EE7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=Pza587dHEmaA3n1liPswPKkQ9TqagRJ4WY1BKyqxtLM=; b=NOuS816unIvSdB J0gfCgdVVo+fDZ+yc2nsfLSVVPe5js0G+Qs8at1HhWVzzbdBrbdMTK3y6ekB44EisecW6JWBxePYM oAT4Ea7wN2B0vG2miCHMK91qIl8cuRZj81f36SM9cSccesYGmtenupK+EaJcaJ+qRxM/QRNSNPDOU TiTu0Az3QrydXAH2Qpm0Dxko7dXYU40TmUcAiBhzPu79+ggpSR+c85pfbktUuXSMlm/GwZ19aHDq1 0NVrC/zKR34NRCclVGM3qKRRMVx+3ByFa8RnN5ipcFgWDGigfha6DDGnCsAT45UZV+QlQLVRFRkvN VNqpgOW7ebPoyitKKKSQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mD7j5-001MOk-2c; Mon, 09 Aug 2021 16:02:07 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mD7b8-001J3O-Ke for linux-arm-kernel@lists.infradead.org; Mon, 09 Aug 2021 15:53:56 +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 BB55B31B; Mon, 9 Aug 2021 08:53:52 -0700 (PDT) Received: from lpieralisi (e121166-lin.cambridge.arm.com [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6E7A03F718; Mon, 9 Aug 2021 08:53:50 -0700 (PDT) Date: Mon, 9 Aug 2021 16:53:43 +0100 From: Lorenzo Pieralisi To: Boqun Feng Cc: Bjorn Helgaas , Arnd Bergmann , Marc Zyngier , Catalin Marinas , Will Deacon , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Wei Liu , Dexuan Cui , Rob Herring , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-pci@vger.kernel.org, Sunil Muthuswamy , Mike Rapoport Subject: Re: [PATCH v6 8/8] PCI: hv: Turn on the host bridge probing on ARM64 Message-ID: <20210809155343.GA31511@lpieralisi> References: <20210726180657.142727-1-boqun.feng@gmail.com> <20210726180657.142727-9-boqun.feng@gmail.com> <20210803171451.GA15466@lpieralisi> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20210809_085354_869275_032326D0 X-CRM114-Status: GOOD ( 39.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Aug 09, 2021 at 10:38:48PM +0800, Boqun Feng wrote: > On Tue, Aug 03, 2021 at 06:14:51PM +0100, Lorenzo Pieralisi wrote: > > On Tue, Jul 27, 2021 at 02:06:57AM +0800, Boqun Feng wrote: > > > Now we have everything we need, just provide a proper sysdata type for > > > the bus to use on ARM64 and everything else works. > > > > > > Signed-off-by: Boqun Feng > > > --- > > > drivers/pci/controller/pci-hyperv.c | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c > > > index e6276aaa4659..62dbe98d1fe1 100644 > > > --- a/drivers/pci/controller/pci-hyperv.c > > > +++ b/drivers/pci/controller/pci-hyperv.c > > > @@ -40,6 +40,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include > > > #include > > > @@ -448,7 +449,11 @@ enum hv_pcibus_state { > > > }; > > > > > > struct hv_pcibus_device { > > > +#ifdef CONFIG_X86 > > > struct pci_sysdata sysdata; > > > +#elif defined(CONFIG_ARM64) > > > + struct pci_config_window sysdata; > > > > This is ugly. HV does not need pci_config_window at all right > > (other than arm64 pcibios_root_bridge_prepare()) ? > > > > Right. > > > The issue is that in HV you have to have *some* sysdata != NULL, it is > > just some data to retrieve the hv_pcibus_device. > > > > Mmaybe we can rework ARM64 ACPI code to store the acpi_device in struct > > pci_host_bridge->private instead of retrieving it from pci_config_window > > so that we decouple HV from the ARM64 back-end. > > > > HV would just set struct pci_host_bridge->private == NULL. > > > > Works for me, but please note that pci_sysdata is an x86-specific > structure, so we still need to define a fake pci_sysdata inside > pci-hyperv.c, like: > > #ifndef CONFIG_X86 > struct pci_sysdata { }; > #end > > > I need to think about this a bit, I don't think it should block > > this series though but it would be nicer. > > After a quick look into the code, seems that what we need to do is to > add an additional parameter for acpi_pci_root_create() and introduce a > slightly different version of pci_create_root_bus(). A question is: > should we only do this for ARM64, or should we also do this for > other acpi_pci_root_create() users (x86 and ia64)? Another question > comes to my mind is, while we are at it, is there anything else that we > want to move from sysdata to ->private? These questions are out of scope > of this patchset, I think. Maybe it's better that we address them in the > future, and I can send out separate RFC patches to start the discussion. > Does that sound like a plan to you? Yes it does and we can start from ARM64 - what I really don't like is the arch/arm64 dependency with the HV controller driver as I described, being forced to have a struct pci_config_window in the driver is not really nice or clean IMO. Not that I expect any other PCI host bridge driver with ACPI coming anytime soon but even if it is not within set (that we can merge) I'd like to see the decoupling rework done asap, let me put it this way. Thanks, Lorenzo > Regards, > Boqun > > > > > Lorenzo > > > > > +#endif > > > struct pci_host_bridge *bridge; > > > struct fwnode_handle *fwnode; > > > /* Protocol version negotiated with the host */ > > > @@ -3075,7 +3080,9 @@ static int hv_pci_probe(struct hv_device *hdev, > > > dom_req, dom); > > > > > > hbus->bridge->domain_nr = dom; > > > +#ifdef CONFIG_X86 > > > hbus->sysdata.domain = dom; > > > +#endif > > > > > > hbus->hdev = hdev; > > > INIT_LIST_HEAD(&hbus->children); > > > -- > > > 2.32.0 > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel