[lkml]   [1998]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: two CDU-535 inspired patches to 2.1.76

[ sent to the kernel list because the cdu-535 driver may not be the only
one with problems ]

On Wed, 31 Dec 1997, Ken Pizzini wrote:
> Recently the 2.1.x kernels have split out some device driver
> types into their own subdirectories. It has come to my attention
> that this split causes a problem for kernels compiled with the
> Sony CDU-535 driver but without any network drivers. The problem
> stems from the fact that drivers/cdrom/sonycd535.c is the only
> non-network driver which attempts to take advantage of the
> autoirq code. This is somewhat spurious, as it turns out,
> because the interrupt code in sonycd535.c has never been completed.

I'd suggest just _not_ using autoirq from drivers/net/ - the whole this is
just a historical placeholder from when the kernel didn't do autoirq
natively. If you look into drivers/net/autoirq.c, you'll see the real way
to handle it: instead of using the (unsupported) autoirq features you
could just do

/* instead of "autoirq_setup()" */
int irq;
unsigned long irq_mask = probe_irq_on();

... do your stuff ...

/* instead of "autoirq_report()" */
udelay(xxx); /* wait for the interrupts to really happen */
irq = probe_irq_off(irq_mask);

Essentially, the above is as simple as using the functions exported from
autoirq.c - the only reason autoirq.c exists at all is because there are
several drivers that used to use the original much more complex code back
when the generic irq code didn't support probing..

But if you're changing your driver anyway, it's better to update it to the
real interface, rather than using the old backwards-compatibility stuff..


 \ /
  Last update: 2005-03-22 13:41    [W:0.028 / U:3.700 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site