As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Signed-off-by: Alexander Gordeev <[email protected]>
---
drivers/net/ethernet/broadcom/bnx2.c | 15 ++++-----------
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index 9d2deda..3df63b2 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -6206,7 +6206,7 @@ bnx2_free_irq(struct bnx2 *bp)
static void
bnx2_enable_msix(struct bnx2 *bp, int msix_vecs)
{
- int i, total_vecs, rc;
+ int i, total_vecs;
struct msix_entry msix_ent[BNX2_MAX_MSIX_VEC];
struct net_device *dev = bp->dev;
const int len = sizeof(bp->irq_tbl[0].name);
@@ -6229,16 +6229,9 @@ bnx2_enable_msix(struct bnx2 *bp, int msix_vecs)
#ifdef BCM_CNIC
total_vecs++;
#endif
- rc = -ENOSPC;
- while (total_vecs >= BNX2_MIN_MSIX_VEC) {
- rc = pci_enable_msix(bp->pdev, msix_ent, total_vecs);
- if (rc <= 0)
- break;
- if (rc > 0)
- total_vecs = rc;
- }
-
- if (rc != 0)
+ total_vecs = pci_enable_msix_range(bp->pdev, msix_ent,
+ BNX2_MIN_MSIX_VEC, total_vecs);
+ if (total_vecs < 0)
return;
msix_vecs = total_vecs;
--
1.7.7.6
Please submit this patch series when the net-next tree opens back up,
I'm only accepting bug fixes at this time.
Also, please always provide a proper "00/NN" openning posting for a
patch series, that gives background and high level information about
what your patch series is trying to achieve and how it achieves it.
That way people reviewing the patches know what to expect, and why,
and I have exactly one posting to reply to if I apply the whole
series.
Thank you.
On Fri, Jan 31, 2014 at 01:30:51PM -0800, David Miller wrote:
>
> Please submit this patch series when the net-next tree opens back up,
> I'm only accepting bug fixes at this time.
>
> Also, please always provide a proper "00/NN" openning posting for a
> patch series, that gives background and high level information about
> what your patch series is trying to achieve and how it achieves it.
>
> That way people reviewing the patches know what to expect, and why,
> and I have exactly one posting to reply to if I apply the whole
> series.
I *think* this whole series applies to drivers/net (the usual patch sending
tools like "stg mail" insert the diffstat automatically in the 00/nn
message), and it sounds like David is willing to apply them via his tree,
so I'm ignoring these for now. Let me know if you need me to do anything.
Bjorn
On Mon, Feb 10, 2014 at 05:38:14PM -0700, Bjorn Helgaas wrote:
> On Fri, Jan 31, 2014 at 01:30:51PM -0800, David Miller wrote:
> >
> > Please submit this patch series when the net-next tree opens back up,
> > I'm only accepting bug fixes at this time.
> >
> > Also, please always provide a proper "00/NN" openning posting for a
> > patch series, that gives background and high level information about
> > what your patch series is trying to achieve and how it achieves it.
> >
> > That way people reviewing the patches know what to expect, and why,
> > and I have exactly one posting to reply to if I apply the whole
> > series.
>
> I *think* this whole series applies to drivers/net (the usual patch sending
> tools like "stg mail" insert the diffstat automatically in the 00/nn
> message), and it sounds like David is willing to apply them via his tree,
> so I'm ignoring these for now. Let me know if you need me to do anything.
I skimmed these and the scsi patches, and I think you were right in
proposing an MSI-X enable function that takes a single "number of vectors"
argument, in addition to pci_enable_msix_range(), which takes a minimum and
a maximum. Obviously the pci_enable_msix_fixed() or whatever could be a
simple #define wrapper or something.
Of the fifty-some net and scsi patches, I counted 23 that use the min ==
max pattern, and it seems a shame to have to repeat that expression.
BTW, I noticed that Documentation/PCI/MSI-HOWTO.txt uses
pci_enable_msi_range() in some of the examples that are really talking
about pci_enable_msix_range() (4.3.1.1 and 4.3.1.2, at least).
Bjorn
On Mon, Feb 10, 2014 at 05:38:14PM -0700, Bjorn Helgaas wrote:
> I *think* this whole series applies to drivers/net (the usual patch sending
> tools like "stg mail" insert the diffstat automatically in the 00/nn
> message), and it sounds like David is willing to apply them via his tree,
> so I'm ignoring these for now. Let me know if you need me to do anything.
Hi Bjorn,
Unlike just a handful of patches concerning pci_enable_msi_range(), some
few dozens of pci_enable_msix_range() updates would be difficult to route
thru your tree. So for net and scsi (and block is pending) I am putting
linux-pci on CC just to let you know what is happening.
> Bjorn
--
Regards,
Alexander Gordeev
[email protected]
On Mon, Feb 10, 2014 at 06:08:03PM -0700, Bjorn Helgaas wrote:
> I skimmed these and the scsi patches, and I think you were right in
> proposing an MSI-X enable function that takes a single "number of vectors"
> argument, in addition to pci_enable_msix_range(), which takes a minimum and
> a maximum. Obviously the pci_enable_msix_fixed() or whatever could be a
> simple #define wrapper or something.
>
> Of the fifty-some net and scsi patches, I counted 23 that use the min ==
> max pattern, and it seems a shame to have to repeat that expression.
(un-CCing [email protected])
Hi Bjorn,
I propose pci_enable_msix_exact(pdev, entries, nvec) rather than
pci_enable_msix_fixed().
Do you prefer this one to return 0/-errno or nvec/-errno?
Do you want pci_enable_msi_exact() in addition to pci_enable_msix_exact()?
Thanks!
> Bjorn
--
Regards,
Alexander Gordeev
[email protected]
On Wed, Feb 12, 2014 at 6:26 AM, Alexander Gordeev <[email protected]> wrote:
> On Mon, Feb 10, 2014 at 06:08:03PM -0700, Bjorn Helgaas wrote:
>> I skimmed these and the scsi patches, and I think you were right in
>> proposing an MSI-X enable function that takes a single "number of vectors"
>> argument, in addition to pci_enable_msix_range(), which takes a minimum and
>> a maximum. Obviously the pci_enable_msix_fixed() or whatever could be a
>> simple #define wrapper or something.
>>
>> Of the fifty-some net and scsi patches, I counted 23 that use the min ==
>> max pattern, and it seems a shame to have to repeat that expression.
>
> (un-CCing [email protected])
>
> Hi Bjorn,
>
> I propose pci_enable_msix_exact(pdev, entries, nvec) rather than
> pci_enable_msix_fixed().
OK, that sounds fine.
> Do you prefer this one to return 0/-errno or nvec/-errno?
0/-errno seems right to me. We are asking for a very specific thing,
and returning nvec doesn't give the caller any additional information
(since the caller supplied nvec in the first place), so simple
success/failure is what I would expect.
> Do you want pci_enable_msi_exact() in addition to pci_enable_msix_exact()?
If there are cases where pci_enable_msi_exact() would be used, I guess
the same arguments would apply, so yes. I haven't looked at the
archives, but I have this nagging feeling that this is exactly what
you proposed initially, and I had some objection. If so, I'm sorry
about changing my mind :)
Bjorn
On Wed, Feb 12, 2014 at 10:00:28AM -0700, Bjorn Helgaas wrote:
> > Do you want pci_enable_msi_exact() in addition to pci_enable_msix_exact()?
>
> If there are cases where pci_enable_msi_exact() would be used, I guess
> the same arguments would apply, so yes. I haven't looked at the
Just a handful of cases in the tree where it could be used for MSI right now,
but still - they do exist.
> archives, but I have this nagging feeling that this is exactly what
> you proposed initially, and I had some objection. If so, I'm sorry
> about changing my mind :)
You are on PCI guard, no worries ;)
> Bjorn
--
Regards,
Alexander Gordeev
[email protected]