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=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 97AE6C636C8 for ; Tue, 20 Jul 2021 14:59:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7D7EC61358 for ; Tue, 20 Jul 2021 14:59:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232284AbhGTOS0 (ORCPT ); Tue, 20 Jul 2021 10:18:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:50634 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235601AbhGTN5u (ORCPT ); Tue, 20 Jul 2021 09:57:50 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (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 B901A6101E; Tue, 20 Jul 2021 14:38:28 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m5qt8-00EWxu-LT; Tue, 20 Jul 2021 15:38:26 +0100 Date: Tue, 20 Jul 2021 15:38:26 +0100 Message-ID: <87v95582zh.wl-maz@kernel.org> From: Marc Zyngier To: Boqun Feng Cc: Bjorn Helgaas , Arnd Bergmann , Catalin Marinas , Will Deacon , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Wei Liu , Dexuan Cui , Lorenzo Pieralisi , Rob Herring , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , 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: [RFC v5 8/8] PCI: hv: Turn on the host bridge probing on ARM64 In-Reply-To: <20210720134429.511541-9-boqun.feng@gmail.com> References: <20210720134429.511541-1-boqun.feng@gmail.com> <20210720134429.511541-9-boqun.feng@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: boqun.feng@gmail.com, bhelgaas@google.com, arnd@arndb.de, catalin.marinas@arm.com, will@kernel.org, kys@microsoft.com, haiyangz@microsoft.com, sthemmin@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, lorenzo.pieralisi@arm.com, robh@kernel.org, kw@linux.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-pci@vger.kernel.org, sunilmut@microsoft.com, rppt@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org On Tue, 20 Jul 2021 14:44:29 +0100, 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; > +#endif Am I the only one who find this rather odd? Nothing ever populates this data structure on arm64, and its only purpose seems to serve as an anchor to retrieve the hbus via container_of(). If that's indeed the case, I'd rather see an arch-specific to_hbus() helper that uses another (preexisting) field as the anchor for arm64. Thanks, M. -- Without deviation from the norm, progress is not possible.