From: Marc Zyngier <maz@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Sascha Bischoff <sascha.bischoff@arm.com>,
Timothy Hayes <timothy.hayes@arm.com>
Subject: Re: [PATCH 1/4] genirq/msi: Add .msi_teardown() callback as the reverse of .msi_prepare()
Date: Mon, 12 May 2025 16:57:00 +0100 [thread overview]
Message-ID: <86tt5pg6ur.wl-maz@kernel.org> (raw)
In-Reply-To: <87h61plx64.ffs@tglx>
On Mon, 12 May 2025 15:29:39 +0100,
Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Sun, May 11 2025 at 17:35, Marc Zyngier wrote:
>
> > While the MSI ops do have a .msi_prepare() callback that is
> > responsible for setting up the relevant (usually per-device)
> > allocation, we don't have a callback reversing this setup.
>
> ..., there is no callback reversing ...
>
> > For this purpose, let's a .msi_teardown() callback. This is
>
> 'let's a ...' is not a sentence. Just say: add a .... calback.
>
> > reliying on the msi_domain_info structure having a non-NULL
>
> ^^^^^ spell check is your friend.
I rely on humans for that. But maybe I should ask someone to put these
recommendations into one of these AI bots, and generate the stuff
automatically. It will be devoid of any actual reasoning, but at least
it will have the "officially sanctioned" verbiage.
>
> > alloc_data field.
> >
> > Nobody is populating this field yet, so there is no change
>
> No driver is ..
No. There is definitely no driver populating this, nor there will ever
be. That's 100% MSI infrastructure.
>
> >
> > +static void msi_domain_ops_teardown(struct irq_domain *domain,
> > + msi_alloc_info_t *arg)
>
> No line break required.
You mean...
>
> > +{
> > +}
> > +
> > static void msi_domain_ops_set_desc(msi_alloc_info_t *arg,
> > struct msi_desc *desc)
... not like this?
> > {
> > @@ -821,6 +826,7 @@ static struct msi_domain_ops msi_domain_ops_default = {
> > .get_hwirq = msi_domain_ops_get_hwirq,
> > .msi_init = msi_domain_ops_init,
> > .msi_prepare = msi_domain_ops_prepare,
> > + .msi_teardown = msi_domain_ops_teardown,
> > .set_desc = msi_domain_ops_set_desc,
> > };
> >
> > @@ -842,6 +848,8 @@ static void msi_domain_update_dom_ops(struct msi_domain_info *info)
> > ops->msi_init = msi_domain_ops_default.msi_init;
> > if (ops->msi_prepare == NULL)
> > ops->msi_prepare = msi_domain_ops_default.msi_prepare;
> > + if (ops->msi_teardown == NULL)
> > + ops->msi_teardown = msi_domain_ops_default.msi_teardown;
> > if (ops->set_desc == NULL)
> > ops->set_desc = msi_domain_ops_default.set_desc;
> > }
> > @@ -1088,6 +1096,10 @@ void msi_remove_device_irq_domain(struct device *dev, unsigned int domid)
> >
> > dev->msi.data->__domains[domid].domain = NULL;
> > info = domain->host_data;
> > +
> > + if (info->alloc_data)
> > + info->ops->msi_teardown(domain, info->alloc_data);
>
> Hmm, that's weird.
>
> Why not call it unconditionally. The empty teardown() default callback
> does not care about @arg being NULL. No?
Because at this point, nothing populates that pointer. It is only
after patch 3 that this pointer is valid. After patch 2, we get a
non-default callback, which should never be presented with a NULL
allocation context.
And since I value keeping things bisectable, it has to happen in this
order.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-05-12 16:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-11 16:35 [PATCH 0/4] genirq/msi: Fix device MSI prepare/alloc sequencing Marc Zyngier
2025-05-11 16:35 ` [PATCH 1/4] genirq/msi: Add .msi_teardown() callback as the reverse of .msi_prepare() Marc Zyngier
2025-05-12 14:29 ` Thomas Gleixner
2025-05-12 15:57 ` Marc Zyngier [this message]
2025-05-12 18:46 ` Thomas Gleixner
2025-05-11 16:35 ` [PATCH 2/4] irqchip/gic-v3-its: Implement .msi_teardown() callback Marc Zyngier
2025-05-12 14:34 ` Thomas Gleixner
2025-05-12 16:09 ` Marc Zyngier
2025-05-12 18:47 ` Thomas Gleixner
2025-05-12 16:30 ` Lorenzo Pieralisi
2025-05-12 17:00 ` Marc Zyngier
2025-05-11 16:35 ` [PATCH 3/4] genirq/msi: Move prepare() call to per-device allocation Marc Zyngier
2025-05-12 14:24 ` Thomas Gleixner
2025-05-12 15:55 ` Marc Zyngier
2025-05-11 16:35 ` [PATCH 4/4] irqchip/gic-v3-its: Use allocation size from the prepare call Marc Zyngier
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=86tt5pg6ur.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=sascha.bischoff@arm.com \
--cc=tglx@linutronix.de \
--cc=timothy.hayes@arm.com \
/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).