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>