Date: Fri, 04 Oct 2013 17:59:06 -0400 From: Douglas Gilbert <dgilbert@interlog.com> To: John-Mark Gurney <jmg@funkthat.com>, sbruno@freebsd.org, "FreeBSD-scsi@freebsd.org" <FreeBSD-scsi@freebsd.org> Subject: Re: pci_alloc_msi is always called, is this bad? Message-ID: <524F3A2A.2010700@interlog.com> In-Reply-To: <20131004165701.GJ56872@funkthat.com> References: <CAFMmRNzWwxe=YVJcC7Lkjqru5eugciwzEQHjgE-Bh-ctOykVNQ@mail.gmail.com> <20131003194704.GG41229@kib.kiev.ua> <1380902209.2621.11.camel@localhost> <20131004165701.GJ56872@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13-10-04 12:57 PM, John-Mark Gurney wrote:
> Sean Bruno wrote this message on Fri, Oct 04, 2013 at 08:56 -0700:
>> I was looking at the recent thread on -stable about mfi(4) and I noted
>> that it appears, if I'm not mistaken, mfi_pci.c::pci_alloc_msi() is
>> *always* invoked regardless of the mfi_msi tuneable. We just ignore the
>> allocated MSI by not setting sc->mfi_irq_rid. Is that harmful?
>>
>> ------------------------------------------------------------------------
>> 240 /* Allocate IRQ resource. */
>> 241 sc->mfi_irq_rid = 0;
>> 242 count = 1;
>> 243 if (mfi_msi && pci_alloc_msi(sc->mfi_dev, &count) == 0) {
>> 244 device_printf(sc->mfi_dev, "Using MSI\n");
>> 245 sc->mfi_irq_rid = 1;
>> 246 }
>>
>>
>> ------------------------------------------------------------------------
>> I would have thought that this would be more correct, avoid calling
>> pci_alloc_msi() if mfi_msi isn't set in the first place.
>> ------------------------------------------------------------------------
>> sc->mfi_irq_ird = 0;
>> count = 1;
>> ret = 0
>> if(mfi_msi)
>> ret = pci_alloc_msi(sc->mfi_dev, &count);
>>
>> if (!ret) {
>> device_printf(sc->mfi_dev, "Using MSI\n");
>> sc->mfi_irq_rid = 1;
>> }
>> ------------------------------------------------------------------------
>
> Per C99 6.5.13 Logical AND operator, para 4:
> Unlike the bitwise binary & operator, the && operator guarantees
> left-to-right evaluation; there is a sequence point after the
> evaluation of the first operand. If the first operand compares equal
> to 0, the second operand is not evaluated.
The C Programming Language, Kernighan and Ritchie,
Copyright 1978. See the middle of page 38.
After explaining this feature they say: "These properties
are critical to writing programs that work."
BTW the book was phototypeset "by a PDP 11/70 running
under the Unix operating system".
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?524F3A2A.2010700>