On Tue, 2016-03-29 at 11:38 -0700, Greg KH wrote:

On Tue, Mar 29, 2016 at 02:27:01PM -0400, Rob Groner wrote:

quoted

On Tue, 2016-03-29 at 08:43 -0700, Greg KH wrote:

quoted

On Tue, Mar 29, 2016 at 11:27:49AM -0400, Rob Groner wrote:

The driver appears to care about what the IRQ number because it uses it
in several other places in the driver: to compare to the incoming IRQ in
the interrupt handler, and to use when the "free_irq" call is required. 
If we shouldn't care what the IRQ is then that means we don't need it
for those things?  Or are you saying we should just keep a pointer to
the pci_dev and reference that IRQ value instead of saving our own?

Hm, maybe this is ok, it just seems odd that you check the irq number in
the handler, that shouldn't be needed at all as the core will not call
you unless the irq you have signed up for has been triggered.

Has that always been true?  I'm pretty sure that code came from a driver
that was around the 2.6.35 era, or earlier.  I will happily remove that
IRQ check, though.  I'm always interested in less code to maintain.
Don't I still need to keep ahold of the IRQ number to call free_irq()
when the resources are released, though?

quoted

quoted

Also, why not submit this for inclusion in the main kernel tree?  That
will make your ongoing maintenance of the code much easier.

I had considered that since this driver currently supports 5 of our
boards (that's better than most of our drivers).  It would be a nice
thing to say it is supported in the kernel.  But I'm not sure how that
will make maintenance easier.  I had a small view into the patch
submitting process earlier this year, and it didn't seem easy...Is it
different if I'm patching my own driver?

You will get other people fixing your bugs and for any api changes, they
will be made automatically.  And, odds are, your driver will get a lot
smaller, there seems to be things in there that aren't needed.  And less
code means less bugs and easier to maintain overtime.

It shouldn't be hard to merge patches for a driver you maintain, if so
then the development process is at fault, and let me know what's going
on and I'll work to help fix it.

That is encouraging and persuasive.  I will make submitting the driver
one of my pet projects.  I need to put a new coat of paint on it before
I submit it for consideration, though.  Do I post to this mailing list
when I'm ready?  Or is there a more pertinent one?

Thanks

Rob