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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 655B8C34021 for ; Mon, 17 Feb 2020 16:26:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 478732072C for ; Mon, 17 Feb 2020 16:26:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728424AbgBQQ0o (ORCPT ); Mon, 17 Feb 2020 11:26:44 -0500 Received: from foss.arm.com ([217.140.110.172]:38150 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727922AbgBQQ0o (ORCPT ); Mon, 17 Feb 2020 11:26:44 -0500 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 C490F30E; Mon, 17 Feb 2020 08:26:43 -0800 (PST) Received: from e121166-lin.cambridge.arm.com (e121166-lin.cambridge.arm.com [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 680E33F68F; Mon, 17 Feb 2020 08:26:40 -0800 (PST) Date: Mon, 17 Feb 2020 16:26:26 +0000 From: Lorenzo Pieralisi To: Marc Zyngier Cc: Pankaj Bansal , Ard Biesheuvel , Makarand Pawagi , Calvin Johnson , stuyoder@gmail.com, nleeder@codeaurora.org, Ioana Ciornei , Cristi Sovaiala , Hanjun Guo , Will Deacon , jon@solid-run.com, Russell King , ACPI Devel Maling List , Len Brown , Jason Cooper , Andy Wang , Varun Sethi , Thomas Gleixner , linux-arm-kernel , Laurentiu Tudor , Paul Yang , netdev@vger.kernel.org, "Rafael J. Wysocki" , Linux Kernel Mailing List , Shameerali Kolothum Thodi , Sudeep Holla , Robin Murphy Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc Message-ID: <20200217162604.GA24829@e121166-lin.cambridge.arm.com> References: <7349fa0e6d62a3e0d0e540f2e17646e0@kernel.org> <20200214161957.GA27513@e121166-lin.cambridge.arm.com> <20200214174949.GA30484@e121166-lin.cambridge.arm.com> <20200217152518.GA18376@e121166-lin.cambridge.arm.com> <384eb5378ee2b240d6ab7d89aef2d5c7@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <384eb5378ee2b240d6ab7d89aef2d5c7@kernel.org> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Feb 17, 2020 at 03:35:01PM +0000, Marc Zyngier wrote: > On 2020-02-17 15:25, Lorenzo Pieralisi wrote: > > On Mon, Feb 17, 2020 at 12:35:12PM +0000, Pankaj Bansal wrote: > > Hi Lorenzo, > > [...] > > > > > Side note: can you explain to me please how the MSI allocation flow > > > > and kernel data structures/drivers are modeled in DT ? I had a quick > > > > look at: > > > > > > > > drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c > > > > > > > > and to start with, does that code imply that we create a > > > > DOMAIN_BUS_FSL_MC_MSI on ALL DT systems with an ITS device node ? > > > > > > Yes. It's being done for all DT systems having ITS node. > > > > This does not seem correct to me, I will let Marc comment on > > the matter. > > Unfortunately, there isn't a very good way to avoid that ATM, > other than defering the registration of the irqdomain until > we know that a particular bus (for example a PCIe RC) is registered. > > I started working on that at some point, and ended up nowhere because > no bus (PCI, FSL, or anything else) really give us the right information > when it is actually required (when a device starts claiming interrupts). > > I *think* we could try a defer it until a bus root is found, and that > this bus has a topological link to an ITS. probably invasive though, > as you would need a set of "MSI providers" for each available irqchip > node. Yes I see, it is not trivial - I just raised the point while reading the code to understand how the IRQ domain structures are connected in the DT bootstrap case, I don't think that's an urgent issue to solve, just noticed and reported it to make sure you are aware. Thanks ! Lorenzo