Received: by 2002:a05:6359:6284:b0:131:369:b2a3 with SMTP id se4csp4491014rwb; Tue, 8 Aug 2023 09:11:58 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE/Au50S5NA+XlSIZx66Yu0yUX/WvEy5GhyVjKYSgM/GRoHFGL8q/1Oc15jL8uHy8hNDENZ X-Received: by 2002:a17:906:5dae:b0:994:54af:e282 with SMTP id n14-20020a1709065dae00b0099454afe282mr52394ejv.10.1691511118409; Tue, 08 Aug 2023 09:11:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691511118; cv=none; d=google.com; s=arc-20160816; b=kMknBL34MDayghnpKN33KG4igBQaYiY4foH04sTYXCTxnvJ1L/vIjCRlkNHF3hgUg6 ULRhEyOB4k5Sb9723jwYojs7BUXv2UQK7jW9AGeCqMVwhllHmJKAgS7PjyHDt2uJVL5p KxjYfW9j3JJfCUSini3cM8GJFz1ok2KafB97rESWTabeh5pVhplybE6tb6a3mpptsjlY TlYtiPeJQXw7tplHfcFhJOldfOlHCV5kwZFH3Op8TPd1Bto0jvPsyQWkktc+r1K+jUwk xpysY/BO98qSlo8iMR7dez/9dSG+XyKqmOnWoI1Lsm00hq4CNVNaXQdg1kJgt4ATzLgH hREg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature; bh=1dUO0Pa0nFbqm2izS4jxDM9ZdIDKdryWE8xulIaqawI=; fh=MfT9EG7wA62MHmmXGGcNQnCxNR+w2c2u2FipGaLZ2ok=; b=ywEWZ4u4ndHz5JmalJ6/K8MlrleCEU8C03IY0YlsiD6wNkARMxjjMwLSbQChZxAzc/ b6jyOY0MnJAvM1m6xI9wB5wOxvl2w7CJ9GMxuVioCP6c+SSXxFjaXGi0PGtjViuZE06T Lc/AryIH3VhXtOYkKQ/t+7LbR01/3wm7WrTVRRFber2MgaR7AgP+XXnx0e2usXOhTkE+ 1Dm3sPI/kls/qQY+AfJ/xWC5VE9xiopxVJLoh1yPNb3pn1mCIrvMI3fj/11jEVyQYCB/ MnVnP5SaeSie6lxJIB3hC5B486PFAdnrXlL61qqJke785lcgrW4odkaRmBdyQvqQyavp Nyfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=McPNo2lf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n22-20020a170906379600b0099cb991ba16si3757751ejc.314.2023.08.08.09.11.09; Tue, 08 Aug 2023 09:11:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=McPNo2lf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232007AbjHHQJv (ORCPT + 99 others); Tue, 8 Aug 2023 12:09:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231807AbjHHQHy (ORCPT ); Tue, 8 Aug 2023 12:07:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3048976A4; Tue, 8 Aug 2023 08:46:14 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 356A762557; Tue, 8 Aug 2023 13:17:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DE47C433C8; Tue, 8 Aug 2023 13:17:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691500645; bh=bIdTKs+XJSSYo9nmEk8w4qlYxgAKUeHbpejGGCNfpP8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=McPNo2lfEjaEdqKynfZ1K+aBmcZ4YYIeVte/2s2vh5nLPjsV4zK8sJIVfpxCc7crr sDBGoRIO5LJCHaR77v68/J53DyRLx71gtm3zc1q1VOESQqBciSKl4OeFOBQVSPMd0S +tBpc5vokh/WWYwp0KB/adwLXL4vh9T5H99097FN3ekyEWjRbxQlUhwtyYf+fLzfY+ NItyKZlA8+itKJ2p2ERAxkbIINwuG4v63bcdxovstp+yn724if/OpATk3O8McX4G8m CB3X6UnRJxGyxAaSluC5CbBaGo5curysvokB2eW3Z97rh38FOsSdo5qHmeplImgc93 W5ZpsOrULl9RA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1qTMaR-0038Tj-Bu; Tue, 08 Aug 2023 14:17:23 +0100 Date: Tue, 08 Aug 2023 14:17:22 +0100 Message-ID: <865y5phdwd.wl-maz@kernel.org> From: Marc Zyngier To: Sunil V L Cc: Andy Shevchenko , linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, Jonathan Corbet , Paul Walmsley , Palmer Dabbelt , Albert Ou , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" , Len Brown , Daniel Scally , Heikki Krogerus , Sakari Ailus , Greg Kroah-Hartman , Daniel Lezcano , Thomas Gleixner , Anup Patel , Bjorn Helgaas , Robert Moore , Haibo Xu , Andrew Jones , Conor Dooley , Atish Kumar Patra , Anup Patel Subject: Re: [RFC PATCH v1 11/21] swnode: Add support to create early during boot In-Reply-To: References: <20230803175916.3174453-1-sunilvl@ventanamicro.com> <20230803175916.3174453-12-sunilvl@ventanamicro.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/28.2 (aarch64-unknown-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: sunilvl@ventanamicro.com, andriy.shevchenko@linux.intel.com, linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, corbet@lwn.net, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, catalin.marinas@arm.com, will@kernel.org, rafael@kernel.org, lenb@kernel.org, djrscally@gmail.com, heikki.krogerus@linux.intel.com, sakari.ailus@linux.intel.com, gregkh@linuxfoundation.org, daniel.lezcano@linaro.org, tglx@linutronix.de, anup@brainfault.org, bhelgaas@google.com, robert.moore@intel.com, haibo1.xu@intel.com, ajones@ventanamicro.com, conor.dooley@microchip.com, atishp@rivosinc.com, apatel@ventanamicro.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 04 Aug 2023 09:11:05 +0100, Sunil V L wrote: > > Hi Andy, > > On Fri, Aug 04, 2023 at 09:09:16AM +0300, Andy Shevchenko wrote: > > On Thu, Aug 03, 2023 at 11:29:06PM +0530, Sunil V L wrote: > > > From: Anup Patel > > > > > > swnode framework can be used to create fwnode for interrupt > > > controllers. > > > > Why? What is this for? > > Can you elaborate? This commit message is poorly written... > > > > And why firmware node is not enough for ACPI case? > > I assume the fwnode in DT case is already provided by OF. > > > Thanks a lot for the review!. > > You are right, OF provides the fwnode for irqchip drivers. However, for > ACPI case, it is typically created using irq_domain_alloc_named_fwnode > or irq_domain_alloc_fwnode since these are not ACPI devices in the > namespace but from MADT. The fwnode created using > irq_domain_alloc_fwnode() is a simple one which doesn't support properties > similar to the one created by OF framework or software node framework. > Hence, lot of data from the MADT structures need to be cached as > separate structures in the drivers and also would need several ifdefs to > check for ACPI and some amount of code duplication is also required due > to the way DT driver gets the information vs ACPI. > > The beauty of software node framework is, it supports adding properties > and also is a supported fwnode type in __irq_domain_create(). There is no beauty here. Only some extra bloat that we do not need. DT and ACPI exposes very different attributes. One describe the HW, the other one describe an OS abstraction. Pretending that you can summon both into the same infrastructure is a fallacy. You'll just end up with the cross product of both infrastructure, and pollute the rest of the kernel with pointless cruft. > So, if we > can create the fwnode for these irqchip using software node, we can > attach the same properties and the actual irqchip driver which uses the > fwnode doesn't need to have any ACPI vs DT checks. Same driver will work > seamlessly on both DT and ACPI platforms. But the challenge is, > currently swnode expects to be created with sysfs which won't be > available during early boot when irqchip drivers need to be probed. So, > adding support to create without dependency on sysfs help us to reuse > the same framework for irqchip use case also. That's another fallacy. Most irqchips *DO NOT* need to be probed early. Only the root irqchip. Given that this series is about *secondary* interrupt controllers, they absolutely don't need to be probed early. To be clear: I do not intend to merge anything that: - invents yet another way to "abstract" firmware interfaces - adds more "early probe" hacks for non-primary interrupt controllers I have already said that in response to Anup's AIA series, and this equally applies to this series. M. -- Without deviation from the norm, progress is not possible.