Re: [RFC PATCH] add pci_{request,free}_irq take #3

[Frederik Deweerdt <deweerdt@free.fr>]

On Thu, Oct 05, 2006 at 05:59:24PM +0400, Alexey Dobriyan wrote:
> On Wed, Oct 04, 2006 at 09:26:33PM +0000, Frederik Deweerdt wrote:
> > On Wed, Oct 04, 2006 at 02:33:11PM -0600, Matthew Wilcox wrote:
> > > On Wed, Oct 04, 2006 at 08:29:38PM +0000, Frederik Deweerdt wrote:
> > > > I see. Just to be sure that I got the matter right, does the issue boils
> > > > down to a choice between:
> > >
> > > woah, woah, woah, you're getting yourself confused here.
> > yep :), I clearly missed the point you made there:
> > http://lkml.org/lkml/2006/10/3/404
> > I've re-read it, hope I've got it right this time.
> > >
> > > You're looking at what the architectures do here.  We're not concerned
> > > with that, we're concerned with what the device drivers do with whatever
> > > value the architecture has stuck in pdev->irq.
> > Not sure I get it still though. Is the issue more than just the location
> > of the irq validation code? If yes, could you explain what are the
> > differences between your proposal and Jeff's ?
> >
> > Anyway, let me have another try at summing up the issue:
> >
> > #1
> > - generic irq validation code in include/linux/pci.h
> > - arch specific irq validation code in include/asm/pci.h
> > - is_irq_valid() called by pci_request_irq()
> 
> s/is_irq_valid/valid_irq/g methinks.
The point of the is_ prefix is to make it clear that we're returning 1
if it's true and 0 if it's false. 
<checks thread on return values>
err... you said[1]:
> There are at least 3 idioms:
> [...]
> 2) return 1 on YES, 0 on NO.
> [...]
> #2 should only be used if condition in question is spelled nice:
Which I thought made sense, and that's why the is_ prefix is there now.
Am I missing something?

Regards,
Frederik
[1] http://lkml.org/lkml/2006/8/18/399