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 0AA54C19F29 for ; Wed, 27 Jul 2022 08:02:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229580AbiG0ICr (ORCPT ); Wed, 27 Jul 2022 04:02:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229481AbiG0ICq (ORCPT ); Wed, 27 Jul 2022 04:02:46 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1AAB422ED; Wed, 27 Jul 2022 01:02:45 -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 51A3861645; Wed, 27 Jul 2022 08:02:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6473DC433C1; Wed, 27 Jul 2022 08:02:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658908964; bh=oFIkkeAnr7pbdOUU0Rf2VovOOsOXvFXow9Y98anFXPk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=nu3uQjGzBuXof6HuTHqu3Zbs+UQq/I1YjZ+dKIGVFHKhl8i3LGnFxVfiBRLIyTYQM iN+y0sVuXNHHEDCqHuIChHKhH6gIQonUEBjvNA9sWO96xKT36Q+/ckWWBKmGczPoiF YOBArGwnqQ9l426SjaJaKAYVFkr2LdLT+07irGekkDikfk+UvhVZvHYF1FmpZUDvHV 7Fjeq50Ki40NW4eznO/jPWDtZE14kiSYzbUcHvFNx3uPrN9+wfvqJ1FsXjLMw6gZaN 6KtGjfEbOX+nkWHsDmFGfqd5TucjRCF3hgKGljZygFGcxSn/0ofV7lc25Nnxi9Zijt BgdI0qA3nuNoA== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.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 1oGc0A-00ALOt-13; Wed, 27 Jul 2022 09:02:42 +0100 Date: Wed, 27 Jul 2022 09:02:41 +0100 Message-ID: <877d3zx9su.wl-maz@kernel.org> From: Marc Zyngier To: Frank Li Cc: "jdmason@kudzu.us" , "tglx@linutronix.de" , "robh+dt@kernel.org" , "krzysztof.kozlowski+dt@linaro.org" , "shawnguo@kernel.org" , "s.hauer@pengutronix.de" , "kw@linux.com" , "bhelgaas@google.com" , "kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-pci@vger.kernel.org" , Peng Fan , Aisheng Dong , "kernel@pengutronix.de" , "festevam@gmail.com" , dl-linux-imx , "kishon@ti.com" , "lorenzo.pieralisi@arm.com" , "ntb@lists.linux.dev" Subject: Re: [EXT] Re: [PATCH v3 2/4] irqchip: imx mu worked as msi controller In-Reply-To: References: <20220720213036.1738628-1-Frank.Li@nxp.com> <20220720213036.1738628-3-Frank.Li@nxp.com> <874jza525l.wl-maz@kernel.org> <87wnc6xz6r.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.219.108.64 X-SA-Exim-Rcpt-To: frank.li@nxp.com, jdmason@kudzu.us, tglx@linutronix.de, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org, s.hauer@pengutronix.de, kw@linux.com, bhelgaas@google.com, kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, peng.fan@nxp.com, aisheng.dong@nxp.com, kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com, kishon@ti.com, lorenzo.pieralisi@arm.com, ntb@lists.linux.dev 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: devicetree@vger.kernel.org On Tue, 26 Jul 2022 22:48:32 +0100, Frank Li wrote: > > > > > > +static void imx_mu_msi_irq_handler(struct irq_desc *desc) > > > > > +{ > > > > > + struct imx_mu_msi *msi_data = irq_desc_get_handler_data(desc); > > > > > + u32 status; > > > > > + int i; > > > > > + > > > > > + status = imx_mu_read(msi_data, msi_data->cfg- > > >xSR[IMX_MU_RSR]); > > > > > + > > > > > + chained_irq_enter(irq_desc_get_chip(desc), desc); > > > > > + for (i = 0; i < IMX_MU_CHANS; i++) { > > > > > + if (status & IMX_MU_xSR_RFn(msi_data->cfg->type, i)) { > > > > > + imx_mu_read(msi_data, msi_data->cfg->xRR + i * 4); > > > > > + generic_handle_domain_irq(msi_data->parent, i); > > > > > > > > Why the parent? You must start at the top of the hierarchy. > > [Frank Li] Do you means that should be msi_data->msi_domain instead > of msi_data->parent? Indeed. you must *not* bypass the hierarchy, and the top level of the hierarchy has to implement whatever is required by the interrupt flow. > > > > > > > > > > + } > > > > > + } > > > > > + chained_irq_exit(irq_desc_get_chip(desc), desc); > > > > > > > > If your MSIs are a chained interrupt, why do you even provide an > > > > affinity setting callback? > > > > > > [Frank Li] it will be crash if no affinity setting callback. > > > > Then you have to fix your driver. > > [Frank Li] After debug, msi_domain_set_affinity() have not did null check for (parent->chip->irq_set_affinity). > I think impact by using dummy set_affinity is minimized. > > int msi_domain_set_affinity(struct irq_data *irq_data, > const struct cpumask *mask, bool force) > { > struct irq_data *parent = irq_data->parent_data; > struct msi_msg msg[2] = { [1] = { }, }; > int ret; > > ret = parent->chip->irq_set_affinity(parent, mask, force); > if (ret >= 0 && ret != IRQ_SET_MASK_OK_DONE) { > BUG_ON(irq_chip_compose_msi_msg(irq_data, msg)); > msi_check_level(irq_data->domain, msg); > irq_chip_write_msi_msg(irq_data, msg); > } > > return ret; > } No. Changing the affinity of an interrupt must not affect the affinity of another. Given that this is a chained handler, you *cannot* satisfy this requirement. So you can't change the affinity at all. N, -- Without deviation from the norm, progress is not possible.