Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757585Ab2HQOWg (ORCPT ); Fri, 17 Aug 2012 10:22:36 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:39687 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757439Ab2HQOWW (ORCPT ); Fri, 17 Aug 2012 10:22:22 -0400 MIME-Version: 1.0 In-Reply-To: <20120817081907.GI2246@dhcp-26-207.brq.redhat.com> References: <447517b3acece13b7e7ce86fdd4d73abe28d81f4.1345124063.git.agordeev@redhat.com> <20120817081907.GI2246@dhcp-26-207.brq.redhat.com> From: Bjorn Helgaas Date: Fri, 17 Aug 2012 08:22:00 -0600 Message-ID: Subject: Re: [PATCH 4/5] PCI, MSI: Enable multiple MSIs with pci_enable_msi_block_auto() To: Alexander Gordeev Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Thomas Gleixner , Suresh Siddha , Yinghai Lu , Jeff Garzik , Matthew Wilcox , linux-doc@vger.kernel.org, x86@kernel.org, linux-pci@vger.kernel.org, linux-ide@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2237 Lines: 45 On Fri, Aug 17, 2012 at 2:19 AM, Alexander Gordeev wrote: > On Thu, Aug 16, 2012 at 10:00:39AM -0600, Bjorn Helgaas wrote: >> On Thu, Aug 16, 2012 at 8:49 AM, Alexander Gordeev wrote: >> > -4.2.3 pci_disable_msi >> > +4.2.3 pci_enable_msi_block_auto >> > + >> > +int pci_enable_msi_block_auto(struct pci_dev *dev, int *count) >> > + >> > +This variation on pci_enable_msi() call allows a device driver to request >> > +the maximum possible number of MSIs. The MSI specification only allows >> > +interrupts to be allocated in powers of two, up to a maximum of 2^5 (32). >> > + >> > +If this function returns 0, it has succeeded in allocating as many >> > +interrupts as the device supports. >> > + >> > +If this function returns a positive number, it indicates that it has >> > +succeeded, but the number of allocated interrupts is less than the number >> > +of interrupts the device supports. The returned value in this case is the >> > +number of allocated interrupts. >> >> Seems like it would be simpler to avoid the special case of returning >> zero. You could return a negative value for failure, otherwise return >> the number of interrupts allocated. > > But this special case is important, because some drivers would not get > satisfied with just any number of interrupts allocated (i.e. few Intel AHCI > chips (seems) have hardware logic that compares qmask vs qsize and simply > falls back to single interrupt if they are not equal). > > So I see the fact that maximum possible number of interrupts were allocated > at least as important than the number itself. > >> Then you could also dispense with the "int *count" argument, because >> the caller could just look at the return value. > > What about returning the number of allocated interrtupts while storing the > number of supported interrupts to "int *count" (or maxcount)? I like that idea a lot better because then you don't need a special case to interpret the return value. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/