linux-kernel - Re: [PATCH 4/5] PCI, MSI: Enable multiple MSIs with pci_enable_msi_block

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 17 Aug 2012 08:22:00 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Alexander Gordeev <agordeev@...hat.com>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Jeff Garzik <jgarzik@...ox.com>,
	Matthew Wilcox <willy@...ux.intel.com>,
	linux-doc@...r.kernel.org, x86@...nel.org,
	linux-pci@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [PATCH 4/5] PCI, MSI: Enable multiple MSIs with pci_enable_msi_block_auto()

On Fri, Aug 17, 2012 at 2:19 AM, Alexander Gordeev <agordeev@...hat.com> 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 <agordeev@...hat.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/