[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4gz2fEv=23Ju0OJiYrgYCBe+oc72GCDn37PeRdRbZ8xWA@mail.gmail.com>
Date: Thu, 3 Oct 2013 14:21:12 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Alexander Gordeev <agordeev@...hat.com>
Cc: linux-kernel@...r.kernel.org, Jon Mason <jon.mason@...el.com>,
Dave Jiang <dave.jiang@...el.com>
Subject: Re: [PATCH RFC 34/77] ioat: Update MSI/MSI-X interrupts enablement code
On Thu, Oct 3, 2013 at 1:12 PM, Alexander Gordeev <agordeev@...hat.com> wrote:
> On Wed, Oct 02, 2013 at 11:00:51AM -0700, Williams, Dan J wrote:
>> I see patch 00/77 now and I still don't see the need for ioatdma to be
>> updated. If we fail the subsequent request_irq, the driver will still
>> fall back to trying less interrupts.
>
> In the proposed design pci_enable_msix() will never return a positive value.
> Therefore if the driver is not updated it will fallback to single MSI if
> device->common.chancnt MSI-X vectors were not allocated while it used to
> fallback to a single MSI-X in the same situation.
That's fine. I just don't like how this patch makes the driver more
complex. If we're making things simpler lets not expose msix internal
details and just fallback to msi directly without worrying about the
number of vectors. I think the msix_single_vector intermediate step
should go.
...and now that I look I see a bug in ioat3_irq_reinit.
> Not to mention 'if (err > 0)'
> dead code.
Ok, then just this piece for now, but more preferable to fold it into
a msix_single_vector removal patch.
- if (err < 0)
+ if (err)
goto msi;
- if (err > 0)
- goto msix_single_vector;
--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists