From: Megha Dey <megha.dey@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, marc.zyngier@arm.com,
ashok.raj@intel.com, jacob.jun.pan@linux.intel.com,
megha.dey@linux.intel.com
Subject: Re: [RFC V1 RESEND 5/6] PCI/MSI: Free MSI-X resources by group
Date: Tue, 06 Aug 2019 12:09:57 -0700 [thread overview]
Message-ID: <1565118597.2401.116.camel@intel.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1906291002190.1802@nanos.tec.linutronix.de>
On Sat, 2019-06-29 at 10:08 +0200, Thomas Gleixner wrote:
> Megha,
>
> On Fri, 21 Jun 2019, Megha Dey wrote:
> >
> > +static int free_msi_irqs_grp(struct pci_dev *dev, int group_id)
> > +{
> >
> > +
> > + for_each_pci_msi_entry(entry, dev) {
> > + if (entry->group_id == group_id && entry->irq)
> > + for (i = 0; i < entry->nvec_used; i++)
> > + BUG_ON(irq_has_action(entry->irq +
> > i));
> BUG_ON is wrong here. This can and must be handled gracefully.
>
Hmm, I reused this code from the 'free_msi_irqs' function. I am not
sure why it is wrong to use BUG_ON here but ok to use it there, please
let me know.
> >
> > + }
> > +
> > + pci_msi_teardown_msi_irqs_grp(dev, group_id);
> > +
> > + list_for_each_entry_safe(entry, tmp, msi_list, list) {
> > + if (entry->group_id == group_id) {
> > + clear_bit(entry->msi_attrib.entry_nr, dev-
> > >entry);
> > + list_del(&entry->list);
> > + free_msi_entry(entry);
> > + }
> > + }
> > +
> > + list_for_each_entry_safe(msix_sysfs_entry, tmp_msix,
> > pci_msix, list) {
> > + if (msix_sysfs_entry->group_id == group_id) {
> Again. Proper group management makes all of that just straight
> forward and
> not yet another special case.
>
Yeah, the new proposal of having a group_list would get rid of this.
> >
> > + msi_attrs = msix_sysfs_entry-
> > >msi_irq_group->attrs;
> >
> > +static void pci_msix_shutdown_grp(struct pci_dev *dev, int
> > group_id)
> > +{
> > + struct msi_desc *entry;
> > + int grp_present = 0;
> > +
> > + if (pci_dev_is_disconnected(dev)) {
> > + dev->msix_enabled = 0;
> Huch? What's that? I can't figure out why this is needed and of
> course it
> completely lacks a comment explaining this.
>
Again, I have reused this code from the pci_msix_shutdown() function.
So for the group case, this is not required?
> >
> > + return;
> > + }
> > +
> > + /* Return the device with MSI-X masked as initial states
> > */
> > + for_each_pci_msi_entry(entry, dev) {
> > + if (entry->group_id == group_id) {
> > + /* Keep cached states to be restored */
> > + __pci_msix_desc_mask_irq(entry, 1);
> > + grp_present = 1;
> > + }
> > + }
> > +
> > + if (!grp_present) {
> > + pci_err(dev, "Group to be disabled not
> > present\n");
> > + return;
> So you print an error and silently return
>
This is a void function, hence no error value can be returned. What do
you think is the right thing to do if someone wants to delete a group
which is not present?
> >
> > + }
> > +}
> > +
> > +int pci_disable_msix_grp(struct pci_dev *dev, int group_id)
> > +{
> > + int num_vecs;
> > +
> > + if (!pci_msi_enable || !dev)
> > + return -EINVAL;
> > +
> > + pci_msix_shutdown_grp(dev, group_id);
> > + num_vecs = free_msi_irqs_grp(dev, group_id);
> just to call in another function which has to do the same group_id
> lookup
> muck again.
Even with the new proposal, we are to have 2 sets of functions: one to
delete all the msic_desc entries associated with the device, and the
other to delete those only belonging a 'user specified' group. So we do
need to pass a group_id to these functions right? Yes, internally the
deletion would be straightforward with the new approach.
>
> >
> > +
> > + return num_vecs;
> > +}
> > +EXPORT_SYMBOL(pci_disable_msix_grp);
> Why is this exposed ?
>
As before, I just followed what pci_disable_msix() did <sigh>. Looks
like pci_disable_msix is called from a variety of drivers, thus it is
exposed. Currently, no one will use the pci_disable_msix_grp()
externally, thus it need not be exposed for now.
> Thanks,
>
> tglx
next prev parent reply other threads:[~2019-08-06 18:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-22 0:19 [RFC V1 RESEND 0/6] Introduce dynamic allocation/freeing of MSI-X vectors Megha Dey
2019-06-22 0:19 ` [RFC V1 RESEND 1/6] PCI/MSI: New structures/macros for dynamic MSI-X allocation Megha Dey
2019-06-22 0:19 ` [RFC V1 RESEND 2/6] PCI/MSI: Dynamic allocation of MSI-X vectors by group Megha Dey
2019-06-29 7:59 ` Thomas Gleixner
2019-08-06 19:05 ` Megha Dey
2019-08-07 13:56 ` Thomas Gleixner
2019-08-07 14:18 ` Marc Zyngier
2019-08-11 7:20 ` Thomas Gleixner
2019-08-12 17:54 ` Megha Dey
2019-08-12 17:48 ` Megha Dey
2019-08-12 17:47 ` Megha Dey
2021-01-07 22:30 ` Jacob Keller
2019-06-22 0:19 ` [RFC V1 RESEND 3/6] x86: Introduce the dynamic teardown function Megha Dey
2019-06-29 8:01 ` Thomas Gleixner
2019-08-06 19:06 ` Megha Dey
2019-06-22 0:19 ` [RFC V1 RESEND 4/6] PCI/MSI: Introduce new structure to manage MSI-x entries Megha Dey
2019-06-22 0:19 ` [RFC V1 RESEND 5/6] PCI/MSI: Free MSI-X resources by group Megha Dey
2019-06-29 8:08 ` Thomas Gleixner
2019-08-06 19:09 ` Megha Dey [this message]
2019-08-11 7:18 ` Thomas Gleixner
2019-08-12 18:13 ` Megha Dey
2019-06-22 0:19 ` [RFC V1 RESEND 6/6] Documentation: PCI/MSI: Document dynamic MSI-X infrastructure Megha Dey
2019-08-02 0:24 ` [RFC V1 RESEND 0/6] Introduce dynamic allocation/freeing of MSI-X vectors Bjorn Helgaas
2019-08-06 19:12 ` Megha Dey
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=1565118597.2401.116.camel@intel.com \
--to=megha.dey@intel.com \
--cc=ashok.raj@intel.com \
--cc=bhelgaas@google.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=megha.dey@linux.intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.