porting old device drivers to 2.2.13 kernel

Tuukka Toivonen (tuukkat@ees2.oulu.fi)
Sat, 13 Nov 1999 02:40:03 +0200 (EET)


I have ported couple of drivers (specifically Genius gs105 handheld scanner
and Gravis Ultrasound project drivers from older kernel versions to 2.2.13.
Having uptime 23 days and having used the drivers, they seem to be pretty
stable. However, I'd like to ask few questions because I'm sure
the drivers could be improved... and I'm sure they aren't 100% ok although
they work.

(1) Select vs. Poll. Much thanks to everyone who look if the following
routines are equal (the most interesting part being select_wait vs.
poll_wait):

static int gs105_select(struct inode *inode, struct file *file, \
int type, select_table *st)
{
int tmp, r;
if(type != SEL_IN)
return 0;
if(!buflines && ((r=gs105_get_mem(req_lines = DEFAULT_BUFLINES)) < 0))
return r;
cli();
tmp=RD_BUFSPC;
sti();
if(tmp >= SELECT_TH) {
PRINTK("gs105_select: device is ready (%d bytes available)\n", tmp);
return 1; /* device is ready */
}
PRINTK("gs105_select: device NOT ready\n");
if(st) {
PRINTK("gs105_select: waiting for device to get ready\n");
bytes_missing = SELECT_TH;
ds.process_sleeps = 1;
if(!ds.irq_enabled) {
PRINTK("gs105_select: IRQ not enabled -- will turn on scanner\n");
scanner_operate();
}
}
select_wait(&wq, st);
return 0;
}

static unsigned int gs105_poll(struct file *file, struct poll_table_struct
*wait) {
int tmp, r;

poll_wait(file, &gs_wait_queue, wait);
if (!buflines && ((r = gs105_get_mem(req_lines=DEFAULT_BUFLINES)) <
0)) return r;
cli();
tmp = RD_BUFSPC;
sti();
if (tmp >= POLL_TH) {
PRINTK("gs105_poll: device is ready (%d bytes"
" available)\n", tmp);
return POLLIN | POLLRDNORM; /* device is ready*/
}
PRINTK("gs105_poll: device NOT ready\n");
if (!wait) {
PRINTK("gs105_poll: wait==NULL!\n");
return 0;
}
PRINTK("gs105_poll: waiting for device to get ready\n");
bytes_missing = POLL_TH;
device_status.process_sleeps = 1;
if (!device_status.irq_enabled) {
PRINTK("gs105_poll: IRQ not enabled -- will turn on scanner\n");
scanner_operate();
}
return 0;
}

(2) Maximum kmalloced memory block size:

#define MAX_BLK (4072 - HEADERSIZ) /* <--- don't touch this */
/* max. chunk of mem we can get with kmalloc()
note: this is likely to change in the future */

The original scanner driver is dated 1994/08/13. What kernel version was
latest at that time? What was the kmalloced block limit at that time? How
much it is nowadays? Is kmallocing the right way to allocate DMA-buffer
(with GFP_DMA)? (The driver allocates a linked list of kmalloc'd memory
blocks for the buffer.)

(3) The scanner allocates (request_irq) IRQ with SA_INTERRUPT. Is this
still ok?

(4) While in interrupt handler, the other functions in the driver can be
executed, ie. the interrupt routine is not atomic and accesses to global
variables has to be protected with spin_lock(). Is this true? Is it true
also on a non-SMP system?

The rest are from GUS driver, original driver was for kernel 2.1.x:

(5) Sleeping. Is the following replacement correct?

#define SLEEP( card, ident, time ) \
card -> end_jiffies_##ident = current -> timeout = jiffies + (time); \
interruptible_sleep_on( &(card) -> sleeper_##ident );

was replaced with

#define SLEEP( card, ident, time ) \
card -> end_jiffies_##ident = jiffies + (time); \
interruptible_sleep_on_timeout( &(card) -> sleeper_##ident, (time) );

We also have this macro, which apparently tests if we reached the timeout:

#define TIMEOUT( card, ident ) ( (card) -> end_jiffies_##ident < jiffies )

(6) How to replace the following line (for kernel 2.1) in 2.2.13?

int gus_mmap_pcm( struct file *file, struct vm_area_struct *vma ) {
...
vma -> vm_dentry = dget( file -> f_dentry );

If there's some mailing list specific for driver development, please
redirect me there.

--
| Tuukka Toivonen <tuukkat@ee.oulu.fi>       [PGP public key
| Homepage: http://www.ee.oulu.fi/~tuukkat/       available]
| Try also finger -l tuukkat@ee.oulu.fi
| Studying information engineering at the University of Oulu
+-----------------------------------------------------------

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/