From: Thomas Gleixner <tglx@linutronix.de>
To: Dou Liyang <douliyangs@gmail.com>
Cc: linux-kernel@vger.kernel.org, kashyap.desai@broadcom.com,
shivasharan.srikanteshwara@broadcom.com,
sumit.saxena@broadcom.com, ming.lei@redhat.com, hch@lst.de,
bhelgaas@google.com
Subject: Re: [RFC PATCH v2] gen/irq: Change the way to differentiate between managed and unmanaged interrupts by bitmap
Date: Fri, 23 Nov 2018 19:28:46 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.21.1811231834450.1684@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20181109163849.21699-1-douliyangs@gmail.com>
Dou,
On Sat, 10 Nov 2018, Dou Liyang wrote:
sorry for late reply. Travel, conferences ....
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -673,14 +674,17 @@ static int msix_setup_entries(struct pci_dev *dev, void __iomem *base,
> const struct irq_affinity *affd)
> {
> struct cpumask *curmsk, *masks = NULL;
> + DECLARE_BITMAP(managed, nvec);
This is not working as it creates a variable length array (VLA). We just
got rid of all VLAs in the kernel and the compiler will catch this and
complain.
> struct msi_desc *entry;
> int ret, i;
>
> + memset(managed, 0, sizeof(managed));
> if (affd)
> - masks = irq_create_affinity_masks(nvec, affd);
> + masks = irq_create_affinity_masks(nvec, affd, managed);
So rather than changing the world and everything by adding new arguments,
what about the following:
-struct cpumask *irq_create_affinity_masks(int nvec, const struct irq_affinity *affd);
+struct irq_affinity_desc * irq_create_affinity_masks(int nvec, struct irq_affinity *affd);
struct irq_affinity_desc {
struct cpumask mask;
unsigned long flags;
};
or something like that. Let irq_create_affinity_masks() allocate an array
of those and store the information in the flags field. In the allocation
functions just replace the cpumask pointer with a irq_affinity_desc pointer
and hand that through to the irqdesc core, where you can evaluate the
flags. Way less things to modify and the data structure allows to expand
this in the future without touching all the functions ever again.
Can you please work against the tip irq/core branch as that has already
other changes in the affinity spreading code queued?
Thanks,
tglx
prev parent reply other threads:[~2018-11-23 18:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-09 16:38 Dou Liyang
2018-11-23 18:28 ` Thomas Gleixner [this message]
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=alpine.DEB.2.21.1811231834450.1684@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=bhelgaas@google.com \
--cc=douliyangs@gmail.com \
--cc=hch@lst.de \
--cc=kashyap.desai@broadcom.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=shivasharan.srikanteshwara@broadcom.com \
--cc=sumit.saxena@broadcom.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
all inboxes | Powered by JetHome®