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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 DB9A0C433E1 for ; Sat, 20 Mar 2021 13:04:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AD53361961 for ; Sat, 20 Mar 2021 13:04:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229766AbhCTNDo (ORCPT ); Sat, 20 Mar 2021 09:03:44 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:37419 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229445AbhCTNDd (ORCPT ); Sat, 20 Mar 2021 09:03:33 -0400 Received: from mail-ot1-f42.google.com ([209.85.210.42]) by mrelayeu.kundenserver.de (mreue107 [213.165.67.113]) with ESMTPSA (Nemesis) id 1Ml76o-1m6XOB1yuq-00lUPh; Sat, 20 Mar 2021 14:03:31 +0100 Received: by mail-ot1-f42.google.com with SMTP id g8-20020a9d6c480000b02901b65ca2432cso11238121otq.3; Sat, 20 Mar 2021 06:03:31 -0700 (PDT) X-Gm-Message-State: AOAM533eY9bSmoTrnYCktJEkRqgZS9McvdNKl39zckxoW/ys4RBdNbB+ 77o51YYwzI+8RjjRfJU29sIR1CoCEEvd+1cSh7U= X-Google-Smtp-Source: ABdhPJw4zwmmsaNKkM4+UrHsd7cqgbKPxiSKwfQNVG5CgM2NbMVXP2bS8xIlYgIDSXo8OuDgdznZ0wY5TDkTqICahtg= X-Received: by 2002:a9d:316:: with SMTP id 22mr680626otv.210.1616245409946; Sat, 20 Mar 2021 06:03:29 -0700 (PDT) MIME-Version: 1.0 References: <20210319161956.2838291-2-boqun.feng@gmail.com> <20210319211246.GA250618@bjorn-Precision-5520> <87tup6gf3m.wl-maz@kernel.org> In-Reply-To: <87tup6gf3m.wl-maz@kernel.org> From: Arnd Bergmann Date: Sat, 20 Mar 2021 14:03:13 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 1/2] arm64: PCI: Allow use arch-specific pci sysdata To: Marc Zyngier Cc: Bjorn Helgaas , 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 Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:jQkD8EZZiXJG0Ypa2SFEOUJN7IyHtWyLXTAgYl/PzevvEcaicoE W1seO2Bmw/9Om+F7WZ2aPBQfHWvY3iJvlJoFh+GbbKunCrmXS9n3LMIKG+2kq1cMxxCyvfz KkP4KIyXa2lwrNQQtEm1qkt/WMid2BjUAmw2KS9fgRwS9/KdiokDU+MjiEfP6P1MbqQ0aQy 23p+MdVW9CgXBoQ+uSnIw== X-UI-Out-Filterresults: notjunk:1;V03:K0:gPSBLDs7PeQ=:aj/UnjetFVZlShr7BPYNPB RtBthhnoz35YAwpa3jg7uxBbQWZDNsybR4Yj+44jQyWHue22275kkmHQ7t7xAC4WHipS5cR14 jvTkM+FQz2ZjL1y+m8fW6JLooUbEEEf2JOBS6Afhs8255kE1TzTOyVOY2TPaGd/JimL1OTudF 8rq2gJN+4wI3/226ug4uKT3oDDqaWNmaAhK2/Z/6iRNxvY5/gVtaz8ea+KUrBjOYkbwx/l2Q/ 8750UVHJOFzwsK/gRBPaPCnH0FATYLYEfPMkgycvQFCX52qn4lJX6Np29mPRBeZ3Gl9D/taM7 hCISmUKDGEGuV8B49HLs+Cf5tnPm5arYG3Od3+BkXwpf/PdggvfHp2jiBr0O2RJJ3CymlMd2o s7E6LebuUpRjLUZVWSNNERrK4rv37oGin2gCPD731OQ0uzh/Yn+dAfohTN6DyWUdFYqRZInqk hb/PzcHZQshkPVOJyFa2UtBxBlBJH8IdHiP9OUGzL1gjLKYsOQKwEr/1emdUCFYnzsiqyV0HR s+iCXKX8ZgED+x6SzfIlT/pBZnxm96P/tyoSyIYyKWfc2pVmq31fOkIy6rxT3/MIg== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 20, 2021 at 1:54 PM Marc Zyngier wrote: > On Fri, 19 Mar 2021 21:12:46 +0000, > > > > Ugh. pci_root_bus_fwnode() is another callback to find the > > irq_domain. Only one call, from pci_host_bridge_msi_domain(), which > > itself is only called from pci_set_bus_msi_domain(). This feels like > > another case where we could simplify things by having the host bridge > > driver figure out the irq_domain explicitly when it creates the > > pci_host_bridge. It seems like that's where we have the most > > information about how to find the irq_domain. > > Urgh. This is a perfect copy paste of the x86 horror, warts and all. > I can't say I'm thrilled (another way to say "Gawd, Noes! Never!"). > > One thing I am sure of is that I do not want to add more custom > indirection to build the MSI topology. We barely got rid of the > msi_controller structure, and this is the same thing by another > name. Probably worse, actually. > > In this case, I don't see the point in going via a fwnode indirection > given that there is no firmware tables the first place. > > As for finding the irq domain from the host bridge, that's not doable > in most cases on arm64, as it is pretty likely that the host bridge > knows nothing about MSIs when they are implemented in the GIC (see my > recent msi_controller removal series that has a few patches about > that). > > Having an optional callback to host bridges to obtain the MSI domain > may be possible in some cases though (there might be a chicken/egg > problem for some drivers though...). I would expect that the host bridge driver can find the MSI domain at probe time and just add a pointer into the pci_host_bridge structure. 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 8A022C433C1 for ; Sat, 20 Mar 2021 13:05:38 +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 1DA5A6196F for ; Sat, 20 Mar 2021 13:05:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1DA5A6196F 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=S0vg3385SOMNZD4yGBV6gagiFMOdg1C65IA6xHHXZEo=; b=Ugtqn0azU8XSco6f49119zz57 3YNKzuuua4KL5XPoRu1fNyF4JT9L7qi+1wFwcf7Ler8BrZOZxCRzyGbjYBxgkKHEh23tvmWSkJatE lIBEsNYdGDmetIBxYM4f6N0rjSIjKkqin9bnDtE8+bYmVLsqtlO48JFZ/+1Ol7RA4ti9M9OyhwcbY 5lfb9WLD6LtDHxkDsaj40wprKluTnl947i/FYCo/SCF7OY+QkN2v2yHSMm3uMaTB9kb3TgrvfdI/p Q+96sLcR/sQ3QzMFpekocAPiDBn0vttcUE8iCRewVMOTmjSeyHgZe2zbL/ceIlpDtX9MP9rWvJtVE RlPd52LDw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lNbGV-008r5e-H7; Sat, 20 Mar 2021 13:03:39 +0000 Received: from mout.kundenserver.de ([212.227.126.135]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lNbGQ-008r5A-LH for linux-arm-kernel@lists.infradead.org; Sat, 20 Mar 2021 13:03:37 +0000 Received: from mail-ot1-f50.google.com ([209.85.210.50]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1My6xz-1lbxj11ps7-00zZNr for ; Sat, 20 Mar 2021 14:03:32 +0100 Received: by mail-ot1-f50.google.com with SMTP id k14-20020a9d7dce0000b02901b866632f29so11246518otn.1 for ; Sat, 20 Mar 2021 06:03:30 -0700 (PDT) X-Gm-Message-State: AOAM532Uny3o9c9dV9mQUKsAYQScE1eQTscw/YU3nnu5LH0XsbEqczpv RiDr8HKUnS+Af6ZJwZ/zPaK/ywiSOZCTR/kfdyA= X-Google-Smtp-Source: ABdhPJw4zwmmsaNKkM4+UrHsd7cqgbKPxiSKwfQNVG5CgM2NbMVXP2bS8xIlYgIDSXo8OuDgdznZ0wY5TDkTqICahtg= X-Received: by 2002:a9d:316:: with SMTP id 22mr680626otv.210.1616245409946; Sat, 20 Mar 2021 06:03:29 -0700 (PDT) MIME-Version: 1.0 References: <20210319161956.2838291-2-boqun.feng@gmail.com> <20210319211246.GA250618@bjorn-Precision-5520> <87tup6gf3m.wl-maz@kernel.org> In-Reply-To: <87tup6gf3m.wl-maz@kernel.org> From: Arnd Bergmann Date: Sat, 20 Mar 2021 14:03:13 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 1/2] arm64: PCI: Allow use arch-specific pci sysdata To: Marc Zyngier Cc: Bjorn Helgaas , 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 X-Provags-ID: V03:K1:BqbVZUx8ubA5gdKXMg7FJlOy1gonMnkUKloha+DDe5j6gSiquy2 6rWLY5nCw0lDc4h7orrjpKpYGTrdTghjO5w2E4mzXYcz34ZuPInhzedevHyJ+VEVhl9PBc5 lxK8aDG6JZQn+qCCOYrCXcNHQhtbZYRSIXz8sWJ9JcoqrgWtXLXyT8QCKVKfsX+n0KQ8AMB UjS/MVX2De0PWEcZiW4QA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Fwt7Qv7bYgk=:PWOWcV5C6a8TUi8NIvPv9s A+TMRgqty843KdqQukqmy0muBWcP2DMpz18pfSp5dvLuSuCXEEyLW18hB0/AQ/LXu3U/14OLX ChpQ756Q+iRUC/l4bhsdAD7073dyNz1ciXiBwpgnWzsfMCMyskDuZkrj9MTbaS1AwFcPdjucj DTruWG6HqxHbBSZHrOfI+bMBW5yNrY+FvG7TmhFmv6rDjIfHKA8/vcBrNjvh8zSGD4ljww+54 DXNaPOp4MJeyXZiWuUxtAhcRsI7PoD0XTnilwH+puB68vLBBYQ/ncXtUJ0vWPeVt8zGTUPNPP 4FHh/7wVaMJIMujeKYJGxoi4/zb/DiSRcKryJWTNh6t8gRuqFh9SAFHvniOiCfUkazEzVL15J BKmil0IuC4z8EErJzv7ySm6NvSpgHkdkFvpFFl9vYkQpEdoI7G1+nGM+LtSURyFhbjNoDpL5W HwW/7BGLhuNy0xFymKNoDyQEA1ooanI01lrByQ9pbfQJpbzxMfThD7eOTcAtXo5XFza14J+bU 60pjQSyDf8UPLhir+FSIw+7FlYCULGMovPiBEG+urj9Uv+C9zu/3v2Bkev76fDuzw== X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210320_130334_855826_1B450428 X-CRM114-Status: GOOD ( 26.05 ) 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 Sat, Mar 20, 2021 at 1:54 PM Marc Zyngier wrote: > On Fri, 19 Mar 2021 21:12:46 +0000, > > > > Ugh. pci_root_bus_fwnode() is another callback to find the > > irq_domain. Only one call, from pci_host_bridge_msi_domain(), which > > itself is only called from pci_set_bus_msi_domain(). This feels like > > another case where we could simplify things by having the host bridge > > driver figure out the irq_domain explicitly when it creates the > > pci_host_bridge. It seems like that's where we have the most > > information about how to find the irq_domain. > > Urgh. This is a perfect copy paste of the x86 horror, warts and all. > I can't say I'm thrilled (another way to say "Gawd, Noes! Never!"). > > One thing I am sure of is that I do not want to add more custom > indirection to build the MSI topology. We barely got rid of the > msi_controller structure, and this is the same thing by another > name. Probably worse, actually. > > In this case, I don't see the point in going via a fwnode indirection > given that there is no firmware tables the first place. > > As for finding the irq domain from the host bridge, that's not doable > in most cases on arm64, as it is pretty likely that the host bridge > knows nothing about MSIs when they are implemented in the GIC (see my > recent msi_controller removal series that has a few patches about > that). > > Having an optional callback to host bridges to obtain the MSI domain > may be possible in some cases though (there might be a chicken/egg > problem for some drivers though...). I would expect that the host bridge driver can find the MSI domain at probe time and just add a pointer into the pci_host_bridge structure. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel