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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id E7537C4332F for ; Wed, 8 Nov 2023 18:37:20 +0000 (UTC) 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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1UoKlqQAgSDixIhiTinBpb1ELAqeqmv3asN0zl4xBjc=; b=Y5bdqHnLIs0dKg 588l144yJfJpqdrzRMpVbySvoN9GELScSUGvJ6xeu8SULQhhlqVTpvhFvJ6V9BNMyx+yi1BoolUot csrxmiIH9YV7H20Xt7xljeKPUJkAZwXObtbOh4QWFMbuH0Vof25AB5aYiy7i7ryUQxgDw5+59Bngl vNFkE21mZxBZhyi81XthiYmjd/Tw3o+KVScQVQOaBJIpzuz5fkw+yGW0f/nGdLHdGryuMmk4MUuan InCu9vcsQW5QkOrRBGxjH0aSCGy+0bPeY/fUrjRnrthNg5i4hRWrJUNtTbarOBptlDG6ZzP/J3e/o VBSjE15yzOebhVVWvpQA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r0nQQ-004VaC-1i; Wed, 08 Nov 2023 18:37:14 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r0nQK-004VYj-0U; Wed, 08 Nov 2023 18:37:12 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 4C0BE616F5; Wed, 8 Nov 2023 18:37:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2E37C433C7; Wed, 8 Nov 2023 18:37:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1699468625; bh=EoZDLxwmLFbEEIkyOEmztWMHpHCSGiYEo4ayX1PT9GY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=GPHv4DtiTNP/0xV1Zk9vqsAbNJUeKn0ZJKyBIpObozF5wckFlaJGMe4CNBfdiOI8d gFRKV7FHCWQYH9IN+bD+8yBXzmTkcCNIkd7ietT4ZSPSBAgDkVqh4s6HVLzl+zmRRc HhYwTYSI0dS7lXRzfwNnkZE19FBS/IVOt7h385+r+XZyWMYGXr2Z+bDlLLp/FjclZ0 94Rqnp7IPuCKVgysW/jZttyZQGjUUQJsHtmuOSZpUG4YoOsvs7s/LtgntArPAEj6I+ w9kLmzAcyhCLPFYdnwf9g4iudvMu0qn4Gb8KHiTb7Z4HypxrLZl2z2Ij/lL2k4hm3X dzhS2/GBDPGGw== Received: from [185.201.63.253] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1r0nQD-00BW1k-GG; Wed, 08 Nov 2023 18:37:02 +0000 Date: Wed, 08 Nov 2023 18:36:13 +0000 Message-ID: <87leb85bz6.wl-maz@kernel.org> From: Marc Zyngier To: Sunil V L Cc: Bjorn Helgaas , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, linux-serial@vger.kernel.org, Catalin Marinas , Will Deacon , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Rafael J . Wysocki" , Len Brown , Bjorn Helgaas , Anup Patel , Thomas Gleixner , Greg Kroah-Hartman , Jiri Slaby , Conor Dooley , Andrew Jones , Atish Kumar Patra , Haibo Xu Subject: Re: [RFC PATCH v2 06/21] RISC-V: Kconfig: Select deferred GSI probe for ACPI systems In-Reply-To: References: <20231106221606.GA264641@bhelgaas> 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/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.201.63.253 X-SA-Exim-Rcpt-To: sunilvl@ventanamicro.com, helgaas@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, linux-serial@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, rafael@kernel.org, lenb@kernel.org, bhelgaas@google.com, anup@brainfault.org, tglx@linutronix.de, gregkh@linuxfoundation.org, jirislaby@kernel.org, conor.dooley@microchip.com, ajones@ventanamicro.com, atishp@rivosinc.com, haibo1.xu@intel.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231108_103708_292628_A108644A X-CRM114-Status: GOOD ( 28.31 ) X-BeenThere: linux-riscv@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-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Wed, 08 Nov 2023 09:53:14 +0000, Sunil V L wrote: > > That's partly correct. APLIC platform devices are created prior to PCI > host bridges added. But the actual APLIC driver which creates the > irqdomain will be probed as a regular platform driver for the APLIC > device. The platform driver probe will happen using DD framework and > devices don't have any dependency on APLIC which can cause device probe > prior to APLIC driver probe. > > DT supports fw_devlink framework which makes it easier for IRQ devices > to use regular platform drivers and produces-consumers are probed in the > order without requiring drivers to do deferred probe. But I don't see > that supported for ACPI framework. Also, the way PNP devices get added > there is an assumption that interrupt controller is already setup fully. > > With this new use case in RISC-V, here are the alternatives I am aware of. > > 1) Use core_initcall() in the APLIC drivers which makes APLIC driver to > be probed prior to PNP or PCI INTx devices. But this was ruled out in > the context of DT from Marc. > > 2) Like the approach tried in this series, add support for deferred > probe in drivers. This will be invasive change requiring many drivers to > change like you pointed. > > I don't know which is less evil or if there is any other alternative > which I am not aware of. > > Thomas/Marc, could you allow APLIC (and PLIC) irqchip drivers to use > core_initcall() for ACPI? I don't have a say about this anymore, so this is only a passing comment, which you are free to cast aside. My personal view is that if you need to rely on core_initcall() for a particular firmware interface, then your architecture will end-up being an unmaintainable ball of hacks, with conflicting requirements and increasingly diverging behaviours. Those who had the 'privilege' to deal with the 32bit ARM transition to DT will understand what I mean. Having to rely on initcalls can only mean two things: - you're missing crucial topology information that will eventually bite you where it hurts, and you're better off going back to the drawing board to fix it before any HW ships, - you're not making use of the kernel's dependency management infrastructure, which is pretty sad. Yes, it is DT specific for now, but nothing prevents you from improving it to make it grok another firmware interface. But as I said, I don't have much skin in that game anymore. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv