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=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 1F577C433E0 for ; Sat, 20 Mar 2021 12:55:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D688961973 for ; Sat, 20 Mar 2021 12:55:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229841AbhCTMzX (ORCPT ); Sat, 20 Mar 2021 08:55:23 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:49457 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229505AbhCTMzK (ORCPT ); Sat, 20 Mar 2021 08:55:10 -0400 Received: from mail-ot1-f51.google.com ([209.85.210.51]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1N6sON-1lkjHX1Upr-018KVg; Sat, 20 Mar 2021 13:55:08 +0100 Received: by mail-ot1-f51.google.com with SMTP id l23-20020a05683004b7b02901b529d1a2fdso11205085otd.8; Sat, 20 Mar 2021 05:55:07 -0700 (PDT) X-Gm-Message-State: AOAM533WbbEcgQWjQosCwsVh8o65iilFHytyV2IXZYZIzH+3ttM7CU5z oaHHJ3h4Z14M4EPydV1999HCY/wK6tTNQsVIF/A= X-Google-Smtp-Source: ABdhPJxfJjFtVcXJVTzNQbZX61NIbImCp304YJaZ1bespXEDPPNSNNKZMiQFU3RpZzf8rAsn4Jwio7QzZOKXntzCFwc= X-Received: by 2002:a05:6830:148c:: with SMTP id s12mr4900234otq.251.1616244906923; Sat, 20 Mar 2021 05:55:06 -0700 (PDT) MIME-Version: 1.0 References: <20210319161956.2838291-2-boqun.feng@gmail.com> <20210319211246.GA250618@bjorn-Precision-5520> In-Reply-To: <20210319211246.GA250618@bjorn-Precision-5520> From: Arnd Bergmann Date: Sat, 20 Mar 2021 13:54:50 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 1/2] arm64: PCI: Allow use arch-specific pci sysdata To: Bjorn Helgaas Cc: Boqun Feng , Bjorn Helgaas , Linux ARM , Linux Kernel Mailing List , Linux on Hyper-V List , linux-pci , Catalin Marinas , Will Deacon , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Wei Liu , Lorenzo Pieralisi , Rob Herring , Clint Sbisa , Ard Biesheuvel , Sunil Muthuswamy , Marc Zyngier Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:3nBsTRjKU4DNvoz6P1XhrvpmUe2H2tSo8FW7//VtMMpKIMWFU59 5LvE5Rx1nrpyksyqctFc2uXS0S/OpKnNXpdurXFpAqI90/1C7+xhQ/zwmogZ+jYulAPORGD dNeW6LLglWNElfFjxknk0nkmpPRQ/ot9K2svvsvzKQn/yuCxAzG826H2zES5GgZyf95YYIm pakNjUSpBxeJ720qndNSQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:j0FktJ2XUn0=:lJoW9JkB4eIpwg7b9EEESz X0lb8lWTNq/QGTiQ2WbUktkPsDiYufirJuh+wEMlvpZUm0zNvhqDhk3AKkVJQ+DkDCiDTz9x+ mGZsJUnFIjxg8ABjCB5aR5UP+Gi0AqgOhs1yxYjczDwjFy2q+UPKWU17gn7fSW1QTfr981uZQ MsoGRX4GgTzPwfYYlc59Bbrhyt011UflGqfesTS2Ltp07YjUEJnVqjtcsO6AoY3yfOLx1y1Xg J3Wj+qRK2RSZDtjiy0HbbDVxniB9/jkLS43Vo5Dw2sAsRP/eRZH6qg8SLcIti/9zD25Kcgtw3 RU9FCiK9ibCzm5rrNPAoz9WLVwaLpe7Mxe8t9/iLA6cAbu4YyZavZ5VpQuCOJrI1dbHe4TIsH 2bn42she0Cqs03K+1ZZZ4EOqsbnF0L7vl6MPXaz09hzHRUgp/mqjhViQqfA8iEy1v+iIbGnj4 H2zWIvCrXiYjlZS7oEcbxKoDj1E9IzesUe9ia9AcssBIx79NP98lHbTbD1uBVRiwVDBuT1ku9 hjx2UxqMn8JT79ps6BhvIBpRVIQP7MVqplXXBiVoxAQtOhK333xHJNN18ZTz7P3Yg== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 19, 2021 at 10:14 PM Bjorn Helgaas wrote: > > However, for a virtualized PCI bus, there might be no enough data in of > > or acpi table to create a pci_config_window. This is similar to the case > > where CONFIG_PCI_DOMAINS_GENERIC=n, IOW, architectures use their own > > structure for sysdata, so no apci table lookup is required. > > > > In order to enable Hyper-V's virtual PCI (which doesn't have acpi table > > entry for PCI) on ARM64 (which selects CONFIG_PCI_DOMAINS_GENERIC), we > > introduce arch-specific pci sysdata (similar to the one for x86) for > > ARM64, and allow the core PCI code to detect the type of sysdata at the > > runtime. The latter is achieved by adding a pci_ops::use_arch_sysdata > > field. > > > > Originally-by: Sunil Muthuswamy > > Signed-off-by: Boqun Feng (Microsoft) > > --- > > arch/arm64/include/asm/pci.h | 29 +++++++++++++++++++++++++++++ > > arch/arm64/kernel/pci.c | 15 ++++++++++++--- > > include/linux/pci.h | 3 +++ > > 3 files changed, 44 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h > > index b33ca260e3c9..dade061a0658 100644 > > --- a/arch/arm64/include/asm/pci.h > > +++ b/arch/arm64/include/asm/pci.h > > @@ -22,6 +22,16 @@ > > > > extern int isa_dma_bridge_buggy; > > > > +struct pci_sysdata { > > + int domain; /* PCI domain */ > > + int node; /* NUMA Node */ > > +#ifdef CONFIG_ACPI > > + struct acpi_device *companion; /* ACPI companion device */ > > +#endif > > +#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN > > + void *fwnode; /* IRQ domain for MSI assignment */ > > +#endif > > +}; > > Our PCI domain code is really a mess (mostly my fault) and I hate to > make it even more complicated by adding more switches, e.g., > ->use_arch_sysdata. > > I think the design problem is that PCI host bridge drivers should > supply the PCI domain up front instead of having callbacks to extract > it. > > We could put "int domain_nr" in struct pci_host_bridge, and the arch > code or host bridge driver (pcibios_init_hw(), *_pcie_probe(), VMD, > HV, etc) could fill in pci_host_bridge.domain_nr before calling > pci_scan_root_bus_bridge() or pci_host_probe(). > > Then maybe we could get rid of pci_bus_find_domain_nr() and some of > the needlessly arch-specific implementations of pci_domain_nr(). > I think we likely could get rid of CONFIG_PCI_DOMAINS_GENERIC, too, > eventually. Agreed. I actually still have a (not really tested) patch series to clean up the pci host bridge registration, and this should make this a lot easier to add on top. I should dig that out of my backlog and post for review. Arnd 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,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 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 0C5C2C433DB for ; Sat, 20 Mar 2021 12:56:32 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 708CC61944 for ; Sat, 20 Mar 2021 12:56:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 708CC61944 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=q0sALtzDjPrfO0rFSDVfeZmxFRWnL/SzOuM0BFOksBU=; b=FPx+3B2WwMqicQUhk0N+Kvwbo vTBG1qNETqPRF0HvFJpGgska4HRiG1jepuwid4sgJA05EF5s72dc/+/n3iwBks1RvbnmWyo4uLKqm Xo1Y/rYBJGh5KY4zJd7wkcmOFvj/rSR9p1vnBhcMi9C9tjwOvMDXDp7hbx4ePnCZqF4q25OEzd0Kp W2ST+apCdpB+T2SA+xPOEuLdNwH5J3A61ATGmBgb7D6ky1/9aHYldDYvZRXeKGdhui6lFNsDROOkA mTEOijfVIoN+8i4varm1OBerpl64kP1KmBYaxSqnMYmEWnSxztFzVQmdfv7D0TyyH/IGy1Y4fUtd4 WYbkRK6Dg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lNb8P-008q1M-NP; Sat, 20 Mar 2021 12:55:17 +0000 Received: from mout.kundenserver.de ([217.72.192.74]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lNb8L-008q0M-1e for linux-arm-kernel@lists.infradead.org; Sat, 20 Mar 2021 12:55:15 +0000 Received: from mail-ot1-f44.google.com ([209.85.210.44]) by mrelayeu.kundenserver.de (mreue108 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MA7Om-1lZ7iB2aZm-00BdLg for ; Sat, 20 Mar 2021 13:55:09 +0100 Received: by mail-ot1-f44.google.com with SMTP id w31-20020a9d36220000b02901f2cbfc9743so10933606otb.7 for ; Sat, 20 Mar 2021 05:55:07 -0700 (PDT) X-Gm-Message-State: AOAM531a87e4syw+zMU2nb+M2KuPe/2LilviGZGZrJQmdFVND8PEpwFK n5HKRTCm2NOlcbUTTioJrz5LTE7GeQTP7YKpmUo= X-Google-Smtp-Source: ABdhPJxfJjFtVcXJVTzNQbZX61NIbImCp304YJaZ1bespXEDPPNSNNKZMiQFU3RpZzf8rAsn4Jwio7QzZOKXntzCFwc= X-Received: by 2002:a05:6830:148c:: with SMTP id s12mr4900234otq.251.1616244906923; Sat, 20 Mar 2021 05:55:06 -0700 (PDT) MIME-Version: 1.0 References: <20210319161956.2838291-2-boqun.feng@gmail.com> <20210319211246.GA250618@bjorn-Precision-5520> In-Reply-To: <20210319211246.GA250618@bjorn-Precision-5520> From: Arnd Bergmann Date: Sat, 20 Mar 2021 13:54:50 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 1/2] arm64: PCI: Allow use arch-specific pci sysdata To: Bjorn Helgaas Cc: Boqun Feng , Bjorn Helgaas , Linux ARM , Linux Kernel Mailing List , Linux on Hyper-V List , linux-pci , Catalin Marinas , Will Deacon , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Wei Liu , Lorenzo Pieralisi , Rob Herring , Clint Sbisa , Ard Biesheuvel , Sunil Muthuswamy , Marc Zyngier X-Provags-ID: V03:K1:NO9PhL+cqYmFCnmGOWJ6bc2j7z+rm0Ndgxg09jvGGWKWBPy9+Lx pTRfht5f4vO/1O3C6GXt/lazl+la9IaRXdZ5g4ijViM6d2mwTaarOPgEdtVMooGtZjjYJLD L6Vgi7jrZhdmxDwVXyaGOFcB0U8Bl1reZUF16zwIar5LLmmW43U1ADcGS3UsOI/Wdqjs/o0 anzl5e4tuYEe+w/jYtJBg== X-UI-Out-Filterresults: notjunk:1;V03:K0:6i5FJRJRcG4=:dw8hMDjUPNs5HSrSgfcO1y Chz2RqURNZNYcAWfy8J+7XFIPtWS9IUpovy0N5wM6GYqto1nzRzNkwG4IFy5M/P6AxvemAsJv k2Asr8wV6gjC8dpYu2U1vxMKtBB2jQ7AZljF2wXFyzrCvUOYqBP4Q8NssQlu6YU9lEfN+RDr2 1stO2zTzPMtVXHYgWMrR+91oQUmhxXC0CXIFMrbPLo+ThOJ2ZtLW2Ncg1NJG4zanDH+ZrujHs NGe+yyf2EoGeFECrVajyzSAVjcTXC25cetN98cGuajbNmB+BgY5f1q4ajBUAFtotGjEXS9jVZ i2tmedfflJ3YeFIWzOmkygErziGs55aH96fn6EPtq79Xrrgk8mGE1OSCEumjct4RypdaajZ6h RiiNDwP1a7kbV76kraLAsWgfPo0ZMgU0GV5eCKffSWOEMut5YRMmL6EkVOxlL6vGM+NBLQw/N b6bslzf7cJM5UbqtEfec8tU60pXBEuviblUtOxSndypyvbN0o5yiWuSMio+deUTCTniy2v3RM KJCCEdLiYkWGbGYItdYFd4RDS1wtSSz0R0dIXrBlzYVXHThgG4MclNtHnwa0COfQQ== X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210320_125513_544686_A0F2226B X-CRM114-Status: GOOD ( 32.25 ) 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 Fri, Mar 19, 2021 at 10:14 PM Bjorn Helgaas wrote: > > However, for a virtualized PCI bus, there might be no enough data in of > > or acpi table to create a pci_config_window. This is similar to the case > > where CONFIG_PCI_DOMAINS_GENERIC=n, IOW, architectures use their own > > structure for sysdata, so no apci table lookup is required. > > > > In order to enable Hyper-V's virtual PCI (which doesn't have acpi table > > entry for PCI) on ARM64 (which selects CONFIG_PCI_DOMAINS_GENERIC), we > > introduce arch-specific pci sysdata (similar to the one for x86) for > > ARM64, and allow the core PCI code to detect the type of sysdata at the > > runtime. The latter is achieved by adding a pci_ops::use_arch_sysdata > > field. > > > > Originally-by: Sunil Muthuswamy > > Signed-off-by: Boqun Feng (Microsoft) > > --- > > arch/arm64/include/asm/pci.h | 29 +++++++++++++++++++++++++++++ > > arch/arm64/kernel/pci.c | 15 ++++++++++++--- > > include/linux/pci.h | 3 +++ > > 3 files changed, 44 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h > > index b33ca260e3c9..dade061a0658 100644 > > --- a/arch/arm64/include/asm/pci.h > > +++ b/arch/arm64/include/asm/pci.h > > @@ -22,6 +22,16 @@ > > > > extern int isa_dma_bridge_buggy; > > > > +struct pci_sysdata { > > + int domain; /* PCI domain */ > > + int node; /* NUMA Node */ > > +#ifdef CONFIG_ACPI > > + struct acpi_device *companion; /* ACPI companion device */ > > +#endif > > +#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN > > + void *fwnode; /* IRQ domain for MSI assignment */ > > +#endif > > +}; > > Our PCI domain code is really a mess (mostly my fault) and I hate to > make it even more complicated by adding more switches, e.g., > ->use_arch_sysdata. > > I think the design problem is that PCI host bridge drivers should > supply the PCI domain up front instead of having callbacks to extract > it. > > We could put "int domain_nr" in struct pci_host_bridge, and the arch > code or host bridge driver (pcibios_init_hw(), *_pcie_probe(), VMD, > HV, etc) could fill in pci_host_bridge.domain_nr before calling > pci_scan_root_bus_bridge() or pci_host_probe(). > > Then maybe we could get rid of pci_bus_find_domain_nr() and some of > the needlessly arch-specific implementations of pci_domain_nr(). > I think we likely could get rid of CONFIG_PCI_DOMAINS_GENERIC, too, > eventually. Agreed. I actually still have a (not really tested) patch series to clean up the pci host bridge registration, and this should make this a lot easier to add on top. I should dig that out of my backlog and post for review. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel