[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131122184447.GB8981@mtj.dyndns.org>
Date: Fri, 22 Nov 2013 13:44:47 -0500
From: Tejun Heo <tj@...nel.org>
To: Alexander Gordeev <agordeev@...hat.com>
Cc: linux-kernel@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
Michael Ellerman <michael@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Ben Hutchings <bhutchings@...arflare.com>,
David Laight <David.Laight@...LAB.COM>,
Mark Lord <kernel@...rt.ca>, "H. Peter Anvin" <hpa@...or.com>,
linux-pci@...r.kernel.org
Subject: Re: [PATCH RFC v2 12/29] PCI/MSI: Introduce pcim_enable_msi*()
family helpers
On Fri, Nov 22, 2013 at 07:44:30PM +0100, Alexander Gordeev wrote:
> On Wed, Nov 20, 2013 at 12:15:26PM -0500, Tejun Heo wrote:
> > The use of @nvec and @maxvec is a bit inconsistent. Maybe it'd be
> > better to make them uniform?
>
> With @maxvec I tried to stress an implication there could be values
> less than @maxvec. While @nvec is more like an exact number.
> Perfectly makes sense to me, but this is personal :)
Oh yeah, I agree but saw a place where @nvec is used for max. Maybe I
was confused. Looking again...
+int pcim_enable_msi_range(struct pci_dev *dev, struct msix_entry *entries,
+ unsigned int nvec, unsigned int minvec)
+
+This variation on pci_enable_msi_block() call allows a device driver to
+request any number of MSIs within specified range minvec to nvec. Whenever
+possible device drivers are encouraged to use this function rather than
+explicit request loop calling pci_enable_msi_block().
e.g. shouldn't that @nvec be @maxvec?
Thanks.
--
tejun
--
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