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 99D14C43334 for ; Mon, 18 Jul 2022 06:43:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233595AbiGRGni (ORCPT ); Mon, 18 Jul 2022 02:43:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230317AbiGRGnh (ORCPT ); Mon, 18 Jul 2022 02:43:37 -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 DF469BE2F for ; Sun, 17 Jul 2022 23:43:35 -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 65C63B80F02 for ; Mon, 18 Jul 2022 06:43:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0789AC341C0; Mon, 18 Jul 2022 06:43:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658126613; bh=vrEY8SK/rT9NSw7YJe2xp+T7whLmeTCEA9XVPCHXbOc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Kbn83e+DUcZ1agpvjYuMt35qHGo6/QPQYXj/23ytlX393Hq935UBrAT3wb/tbeHVU fKnlPFlaI/foBZN8bBlLXnru68DKvAXQZ2mjAky9neuXnVSf7AL6cF9Js1kP/ZUgEo XHKaVHdhK78hw8KwqBbrZujrhuWdG4UHLehlk2OkFcieG2ewB8CogQSmy+0k5GKvlM p0sM3EW5TbndryqCM74dbmBI4wrJSQBPYbMFOpUHG4raoHZpFgbcz1ZrLhtK7up4bS ZvsaC9IS4Xm/5Oa0Zp2fTmGXo/kH4DzBwmKxQ2h+Vz1ScYHQaBApmzvkhYYSRDJlOI buLMEETScIQ+Q== Received: from 82-132-227-210.dab.02.net ([82.132.227.210] 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 1oDKTa-00886G-Ji; Mon, 18 Jul 2022 07:43:30 +0100 Date: Mon, 18 Jul 2022 07:43:20 +0100 Message-ID: <87edyi53av.wl-maz@kernel.org> From: Marc Zyngier To: Huacai Chen Cc: Jianmin Lv , Thomas Gleixner , LKML , loongarch@lists.linux.dev, Hanjun Guo , Lorenzo Pieralisi , Jiaxun Yang , Huacai Chen Subject: Re: [PATCH V15 00/15] irqchip: Add LoongArch-related irqchip drivers In-Reply-To: References: <1657868751-30444-1-git-send-email-lvjianmin@loongson.cn> <87less52bx.wl-maz@kernel.org> <6e9def1e-31fe-787d-1b2b-a328424352f0@loongson.cn> <87ilnw3vlg.wl-maz@kernel.org> <20994a99-b5b1-442d-d23d-2a11ecef24a0@loongson.cn> <87y1wrzto7.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.227.210 X-SA-Exim-Rcpt-To: chenhuacai@kernel.org, lvjianmin@loongson.cn, tglx@linutronix.de, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, 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 Mon, 18 Jul 2022 03:38:09 +0100, Huacai Chen wrote: > > Hi, Marc, > > On Sun, Jul 17, 2022 at 10:43 PM Marc Zyngier wrote: > > > > On Sun, 17 Jul 2022 15:08:14 +0100, > > Huacai Chen wrote: > > > > > > Hi, Marc, Jianmin, > > > > > > I have an idea but I don't know whether it is acceptable: Marc gives > > > an Acked-by for the whole series, then this irqchip series goes > > > through the loongarch tree together with the PCI patches, then we > > > don't need other hacks except the ACPI definitions. > > > > Not sure how this solves the original problem. PCI should never be > > mandatory (it is actually super useful to be able to build a very > > small kernel without too many drivers), and there shouldn't be > > configurations where the kernel doesn't build. > Now, the pci-loongson controller code (A) is in the PCI tree, the pci > enablement code (B) is in the LoongArch tree, and the irqchip code (C) > is in the irqchip tree. If the order for upstream is (A) --> (B) --> > (C), there will be no build error. My above idea is to make sure the > order of (B) and (C) is controlled in the same tree. PCI/MSI is a > mandatory requirement for LoongArch, so I want to avoid some > unnecessary #ifdefs. > > > > > It is also my own responsibility to merge these things, and I'd rather > > not delegate this, specially as it touches a bunch of other > > subsystems. > I know, this is reasonable. Then if we can control the order of > (A)(B)(C) in three trees, the build error can be avoided in the > linux-next tree. This would require stable branches between all three trees, as we don't control the *order* of the merges. I'd have to carry (A) and (B) as part of (C), which is really over the top. Just queue a patch to remove the #ifdef once we're at -rc1 and that things have settled down. This will be simpler for everyone, and will allow everyone to have a clean tree without dragging tons of extra patches. M. -- Without deviation from the norm, progress is not possible.