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 7BB6EC433EF for ; Mon, 18 Jul 2022 06:40:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233574AbiGRGkA (ORCPT ); Mon, 18 Jul 2022 02:40:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233561AbiGRGj6 (ORCPT ); Mon, 18 Jul 2022 02:39:58 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07FA7A196 for ; Sun, 17 Jul 2022 23:39:57 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 9A3176122E for ; Mon, 18 Jul 2022 06:39:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B206C341C0; Mon, 18 Jul 2022 06:39:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658126396; bh=FVtPF9TskivvBpjVAk3wnNABThyB0cXx9cOF72HiF80=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oUHV+4QPa3NcjLBJWd/S8XPY1vwJFVyTfYnugvd+8/wPBUZB+4euZA91ZRUpORVpL OdLFaj4SpyTswtzFxVjSs0e5yzloJ4dU1cxGHraHMw17bnSMuBMgzlAVFradpqT95K wtVXEZie+53z9qlCqBD3gyJ0HjYuTn8zAonBTmR1n0iKoH7sE1gzpDajNi7GF6HKN6 bbtO4mIksLx9pnGAEyUoclX/Y2GhSUe1i1a9IaWLcqYbySPYYHr9fkXiRk3KSoMJkI dwVSPorxFHk0le6Yerqi8PwmAJwwrGdaHfim52TYFixmO9Mu4Wmf0T52Ntj5l3teXk uIbgcwzOpmghw== 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 1oDKQ5-00885P-22; Mon, 18 Jul 2022 07:39:53 +0100 Date: Mon, 18 Jul 2022 07:39:36 +0100 Message-ID: <87fsiy53h3.wl-maz@kernel.org> From: Marc Zyngier To: Jianmin Lv Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, 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: <058aed14-3644-5fc4-8eda-ec645df91836@loongson.cn> 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> <87wncbzteg.wl-maz@kernel.org> <058aed14-3644-5fc4-8eda-ec645df91836@loongson.cn> 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 82.132.227.210 X-SA-Exim-Rcpt-To: 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 02:07:21 +0100, Jianmin Lv wrote: >=20 >=20 >=20 > On 2022/7/17 =E4=B8=8B=E5=8D=8810:49, Marc Zyngier wrote: > > On Sun, 17 Jul 2022 12:29:05 +0100, > > Jianmin Lv wrote: > >>=20 > >>=20 > >>=20 > >> On 2022/7/17 =E4=B8=8B=E5=8D=886:02, Marc Zyngier wrote: > >>> But the other issue is that you seem to call this function from two > >>> different locations. This cannot be right, as there should be only one > >>> probe order, and not multiple. > >>>=20 > >>=20 > >> As we described two IRQ models(Legacy and Extended) in this cover > >> letter, the parent domain of MSI domain can be htvec domain(Legacy) or > >> eiointc domain(Extended). In MADT, only one APIC(HTPIC for htvec or > >> EIOPIC for eiointc) is allowed to pass into kernel, and then in the > >> irqchip driver, only one kind APIC of them can be parsed from MADT, so > >> we have to support two probe order for them. > >=20 > > Do you really have the two variants in the wild? Or is this just > > because this is a possibility? > >=20 >=20 > Currently, there are not CPUs(used for PC and server) based on > LoongArch shipped with only HTPIC, but with both HTPIC and EIOPIC, we > just want to provide two choices for designers(but obviously, EIOPIC > may be enough currently). Do you think we don't have to do like this, > yes? If so, maybe we don't have to support ACPI-way entry for htvec > currently, and do the work in future if required. If the existing HW is only following the 'Extended' model, then I'd suggest you only support this for now. It has two effects: - it simplifies the current code, making it more maintainable and easier to reason about - it sends the message to integrators that 'Extended' is the correct model, and that it is what they should support Now, we don't have much time left to get this series into -next (I will be closing the tree to new features this week, and only queue fixes). So whatever you need to do, please do it quickly so that we can have at least some of this in 5.20. Thanks, M. --=20 Without deviation from the norm, progress is not possible.