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 89E50C04A95 for ; Wed, 28 Sep 2022 07:51:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232892AbiI1HvQ (ORCPT ); Wed, 28 Sep 2022 03:51:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233871AbiI1Huq (ORCPT ); Wed, 28 Sep 2022 03:50:46 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AAA9B3B; Wed, 28 Sep 2022 00:49:10 -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 4E6D9B81F64; Wed, 28 Sep 2022 07:49:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB287C433D6; Wed, 28 Sep 2022 07:49:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664351348; bh=tSFaGvv8+ZTypBsJXfaH7GNqTOxZdKyLPnylrK/B66w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=quSEMugNEUvE770Q4jkKvM5xwTMLbnNlY0TBxM19EQftuqAy5uGWznNXafcGB/h1R TRUSe7Ej6lvL0MSlLCNr/nDD+tAj4D9rM/2Q6p7zg5aSbVQCxFKYtvLlO3Xl89oDsd r6RRooFFRY0e1U5qvfGimqe6UUEJdcZfpeXtR8UH+ICV36EHq3vh6EjrYBss3Y2MXW AR3il1mBrPLntSPNt/uzF7t6AxkSYPkC17cYaCezHPvEq9C9ZVIMvmlzK/EAWxs69a fBnhDnQl6Rjkb8p9HhiF7xZGLA2EqPA2HrPG1JX7s5luvDrk+NkfOVF/444Cpilz2g 58QYZpyzPiHlA== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] 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 1odRoW-00DCT1-PT; Wed, 28 Sep 2022 08:49:05 +0100 Date: Wed, 28 Sep 2022 08:47:57 +0100 Message-ID: <871qrwhrde.wl-maz@kernel.org> From: Marc Zyngier To: Wei Yongjun Cc: Bartosz Golaszewski , Wei Yongjun , Thomas Gleixner , Linus Walleij , , Subject: Re: [PATCH v2 1/3] genirq/irq_sim: Allow both one and two cell bindings In-Reply-To: References: <20220926084428.1792815-1-weiyongjun@huaweicloud.com> <20220926084428.1792815-2-weiyongjun@huaweicloud.com> <865yha8fcs.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: 185.104.136.29 X-SA-Exim-Rcpt-To: weiyongjun1@huawei.com, brgl@bgdev.pl, weiyongjun@huaweicloud.com, tglx@linutronix.de, linus.walleij@linaro.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org 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 Wed, 28 Sep 2022 08:32:25 +0100, Wei Yongjun wrote: > > > > On 2022/9/26 20:55, Marc Zyngier wrote: > > On Mon, 26 Sep 2022 07:24:48 -0400, > > Bartosz Golaszewski wrote: > >> > >> On Mon, Sep 26, 2022 at 10:27 AM Wei Yongjun wrote: > >>> > >>> From: Wei Yongjun > >>> > >>> The IRQ simulator only support one cell binding now, this patch make it > >>> works with either one or two cell bindings, where the cell values map > >>> directly to the irq number and irq flags. > >>> > >>> Signed-off-by: Wei Yongjun > >>> --- > >>> kernel/irq/irq_sim.c | 1 + > >>> 1 file changed, 1 insertion(+) > >>> > >>> diff --git a/kernel/irq/irq_sim.c b/kernel/irq/irq_sim.c > >>> index dd76323ea3fd..73a90b7b6022 100644 > >>> --- a/kernel/irq/irq_sim.c > >>> +++ b/kernel/irq/irq_sim.c > >>> @@ -149,6 +149,7 @@ static void irq_sim_domain_unmap(struct irq_domain *domain, unsigned int virq) > >>> static const struct irq_domain_ops irq_sim_domain_ops = { > >>> .map = irq_sim_domain_map, > >>> .unmap = irq_sim_domain_unmap, > >>> + .xlate = irq_domain_xlate_onetwocell, > >>> }; > >>> > >>> /** > >>> -- > >>> 2.34.1 > >>> > >> > >> You'll need Marc's (Cc'ed) Ack here. > > Hi Marc, > > > > > The question is what will the simulator code do with this information. > > Throw it away? What of 3/4/5 cell bindings? I'd rather see the > > The 3/4/5 cell bindings is selience ignored currently. > > > simulator being extended to deal with arbitrary bindings instead of > > trading a harcoded limit for another one. And also give some > > semantics to the extra cells. > > Would you means we should allow the users to overwrite the xlate callback > or overwrite the domain_ops? Neither. I think the caller should provide an irq_domain_ops structure at domain creation, with the .xlate member populated, and the irq_sim code would add its own ops to it. Providing NULL would ensure we fallback to the existing behaviour. Thanks, M. -- Without deviation from the norm, progress is not possible.