From: Marc Zyngier <maz@kernel.org>
To: Frank Li <frank.li@nxp.com>
Cc: "jdmason@kudzu.us" <jdmason@kudzu.us>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"krzysztof.kozlowski+dt@linaro.org"
<krzysztof.kozlowski+dt@linaro.org>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"kw@linux.com" <kw@linux.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"kernel@vger.kernel.org" <kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Peng Fan <peng.fan@nxp.com>, Aisheng Dong <aisheng.dong@nxp.com>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"festevam@gmail.com" <festevam@gmail.com>,
dl-linux-imx <linux-imx@nxp.com>, "kishon@ti.com" <kishon@ti.com>,
"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"ntb@lists.linux.dev" <ntb@lists.linux.dev>
Subject: Re: [EXT] Re: [PATCH v3 2/4] irqchip: imx mu worked as msi controller
Date: Wed, 27 Jul 2022 09:02:41 +0100 [thread overview]
Message-ID: <877d3zx9su.wl-maz@kernel.org> (raw)
In-Reply-To: <PAXPR04MB918621013E6276D37B56C48488949@PAXPR04MB9186.eurprd04.prod.outlook.com>
On Tue, 26 Jul 2022 22:48:32 +0100,
Frank Li <frank.li@nxp.com> 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.
next prev parent reply other threads:[~2022-07-27 8:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 21:30 [PATCH v3 0/4] PCI EP driver support MSI doorbell from host Frank Li
2022-07-20 21:30 ` [PATCH v3 1/4] irqchip: allow pass down .pm field at IRQCHIP_PLATFORM_DRIVER_END Frank Li
2022-07-20 21:30 ` [PATCH v3 2/4] irqchip: imx mu worked as msi controller Frank Li
2022-07-21 7:57 ` Marc Zyngier
2022-07-21 15:22 ` [EXT] " Frank Li
2022-07-21 15:28 ` Marc Zyngier
2022-07-21 15:35 ` Frank Li
2022-07-26 21:48 ` Frank Li
2022-07-27 8:02 ` Marc Zyngier [this message]
2022-07-27 15:23 ` Frank Li
2022-07-27 15:34 ` Marc Zyngier
2022-07-27 18:29 ` Frank Li
2022-07-27 18:58 ` Frank Li
2022-07-22 7:33 ` Marc Zyngier
2022-07-22 16:12 ` Frank Li
2022-07-20 21:30 ` [PATCH v3 3/4] dt-bindings: irqchip: imx mu work " Frank Li
2022-07-23 18:50 ` Krzysztof Kozlowski
2022-07-25 16:29 ` [EXT] " Frank Li
2022-07-25 16:44 ` Krzysztof Kozlowski
2022-07-25 16:55 ` Frank Li
2022-07-25 20:28 ` Krzysztof Kozlowski
2022-08-10 14:01 ` Rob Herring
2022-08-10 14:20 ` Marc Zyngier
2022-08-10 14:32 ` Jon Mason
2022-07-20 21:30 ` [PATCH v3 4/4] pcie: endpoint: pci-epf-vntb: add endpoint MSI support Frank Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877d3zx9su.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=aisheng.dong@nxp.com \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=frank.li@nxp.com \
--cc=jdmason@kudzu.us \
--cc=kernel@pengutronix.de \
--cc=kernel@vger.kernel.org \
--cc=kishon@ti.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=ntb@lists.linux.dev \
--cc=peng.fan@nxp.com \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).