Re: [PATCH] request_irq() always returns -EINVAL with a NULL handler.

2008-02-03 Thread Rusty Russell
On Sunday 03 February 2008 17:15:02 Andrew Morton wrote: > On Thu, 17 Jan 2008 17:57:58 +1100 Rusty Russell <[EMAIL PROTECTED]> wrote: > > I assume that these ancient network drivers were trying to find out if > > an irq is available. eepro.c expecting +EBUSY was doubly wrong. > > > > I'm not sur

Re: [PATCH] request_irq() always returns -EINVAL with a NULL handler.

2008-02-02 Thread Andrew Morton
On Thu, 17 Jan 2008 17:57:58 +1100 Rusty Russell <[EMAIL PROTECTED]> wrote: > I assume that these ancient network drivers were trying to find out if > an irq is available. eepro.c expecting +EBUSY was doubly wrong. > > I'm not sure that can_request_irq() is the right thing, but these drivers > a

Re: [PATCH] request_irq() always returns -EINVAL with a NULL handler.

2008-01-17 Thread Stephen Hemminger
On Thu, 17 Jan 2008 17:57:58 +1100 Rusty Russell <[EMAIL PROTECTED]> wrote: > I assume that these ancient network drivers were trying to find out if > an irq is available. eepro.c expecting +EBUSY was doubly wrong. > > I'm not sure that can_request_irq() is the right thing, but these drivers > a

[PATCH] request_irq() always returns -EINVAL with a NULL handler.

2008-01-16 Thread Rusty Russell
I assume that these ancient network drivers were trying to find out if an irq is available. eepro.c expecting +EBUSY was doubly wrong. I'm not sure that can_request_irq() is the right thing, but these drivers are definitely wrong. request_irq should BUG() on bad input, and these would have been