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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CC13C433EF for ; Thu, 30 Jun 2022 07:24:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232705AbiF3HYM (ORCPT ); Thu, 30 Jun 2022 03:24:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230271AbiF3HYK (ORCPT ); Thu, 30 Jun 2022 03:24:10 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7F8F2AE13 for ; Thu, 30 Jun 2022 00:24:09 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7AF60B828C5 for ; Thu, 30 Jun 2022 07:24:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E581C34115; Thu, 30 Jun 2022 07:24:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656573847; bh=kht40b/B9e57FLqjsUfGUxjfYslp7XSSkYLU7BgOh94=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=m2v8uf6CCxkF2Ycwnl1T3FZo21XEoiSv7YvAk0tCGRwZZv6WOAQm5lBgc3zbO9tfN Vt1+Ah+Qm79TKuplE5OPojCHEdPuGnVsxIvjMSQTz2yfEAvSyfdvpCObxwF4ZSHXhR UOMFmNPtbJdaGxnz4sSvzfIwNwrWoruUq7ue3APyO7RKwy4pg60k5GQR0gEJTT0fSL 2AasNVNt6o/++drXZge+3KhTL6Mf267unH62QC2fxD4plve+1kR6/mYMCuIP6tK5NS FKgZF3ir6aGWQMW0OOB8DfBnOCofkG7qg/gQL4mE9nsEw50pkWNPjy+ZGd736Whgas InkB1B4YvBgrQ== Received: from 82-132-233-164.dab.02.net ([82.132.233.164] 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 1o6oWx-004GTP-D3; Thu, 30 Jun 2022 08:24:05 +0100 Date: Thu, 30 Jun 2022 08:22:47 +0100 Message-ID: <87o7yaehtk.wl-maz@kernel.org> From: Marc Zyngier To: Jianmin Lv Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, Hanjun Guo , Lorenzo Pieralisi , Jiaxun Yang , Huacai Chen Subject: Re: [PATCH V13 06/13] irqchip/loongson-pch-pic: Add ACPI init support In-Reply-To: References: <1656329997-20524-1-git-send-email-lvjianmin@loongson.cn> <1656329997-20524-7-git-send-email-lvjianmin@loongson.cn> <87v8sj1zs9.wl-maz@kernel.org> 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/27.1 (x86_64-pc-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: 82.132.233.164 X-SA-Exim-Rcpt-To: lvjianmin@loongson.cn, tglx@linutronix.de, linux-kernel@vger.kernel.org, guohanjun@huawei.com, lorenzo.pieralisi@arm.com, jiaxun.yang@flygoat.com, chenhuacai@loongson.cn X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 30 Jun 2022 05:36:40 +0100, Jianmin Lv wrote: > > [...] > >> +static int __init pch_pic_acpi_init(void) > >> +{ > >> + acpi_table_parse_madt(ACPI_MADT_TYPE_BIO_PIC, > > > > Where is this defined? It only appears in the documentation, and > > nowhere else... > > > > It's defined in the patch to ACPICA(which has been merged, please to > see > https://github.com/acpica/acpica/commit/1dc530059a3e6202e941e6a9478cf30f092bfb47). > the patch will be synchronized to linux kernel by maintainer of ACPICA. How can I take this patch upstream if it doesn't even compile? Please make this patch part of your series. There are tons of patches that need Acks from the ACPI maintainers, this is only one of them. > > > >> + pchintc_parse_madt, 0); > >> + > >> + return 0; > >> +} > >> +early_initcall(pch_pic_acpi_init); > > > > Why can't you use IRQCHIP_ACPI_DECLARE here? This is terribly fragile, > > and will eventually break. I really don't want to rely on this. > > > > In early time, the change here is implemented using > IRQCHIP_ACPI_DECLARE, but we found that calling order(during > irqchip_init) of the entry declared using IRQCHIP_ACPI_DECLARE is > depended on the compiling order(driver order in Makefile) of the > driver. For removing the dependency to the compiling order, the new > way here is used(I looked into ARM, it seems that GIC driver uses > IRQCHIP_ACPI_DECLARE, and ITS driver uses early_initcall too.). It's not quite the same. The ITS part that uses early_initcall isn't an actual driver (it only registers a domain, and nothing else). There is also no guarantee that the initcalls at the same priority will execute in any order, and you already have at least two such initcalls (pch_pic_acpi_init, pch_msi_acpi_init, and I haven't quite understood how the rest is probed yet). One possibility would be to drive the whole probing from the root interrupt controller, which is similar to what GICv3 does for the actual ITS driver. You already do this sort of stuff in the CPUINTC driver, so adding to this shouldn't be too hard. M. -- Without deviation from the norm, progress is not possible.