> You are correct that the semantics of release_region() have subtly
> changed, and that in unusual cases, drivers will need to be tweaked to
> accommodate it. I had not thought that any drivers did the sort of
> thing that ftape apparently does. I think that fixing the drivers is
> the correct course of action, not effectively reverting the new
> semantics as you suggest. Especially if ftape is the only example of
> this issue.
Does this count as 'fixing the drivers'? It looks ugly to me, but it's
the only way (still using request/release) I can get parport_pc to load
after being unloaded.
There are mandatory registers (base .. base+2), and optional registers
(base+3 ..). First of all, we check that we can use the mandatory
registers, and when we figure out what type of port it is we request
either 3 or 8 bytes.
If we requested 8 bytes the first time, the check_region (base, 3) will
fail.
This hack requests the region in two chunks. Yuck. Is there a better
way?
Tim.
*/
diff -durN linux-2.3.10-pre1/drivers/misc/parport_pc.c linux/drivers/misc/parport_pc.c
--- linux-2.3.10-pre1/drivers/misc/parport_pc.c Sat Jul 3 10:23:11 1999
+++ linux/drivers/misc/parport_pc.c Sun Jul 4 10:02:26 1999
@@ -1663,7 +1663,9 @@
printk("%s: irq %d detected\n", p->name, probedirq);
parport_proc_register(p);
- request_region (p->base, p->size, p->name);
+ request_region (p->base, 3, p->name);
+ if (p->size > 3)
+ request_region (p->base + 3, p->size - 3, p->name);
if (p->modes & PARPORT_MODE_ECP)
request_region (p->base_hi, 3, p->name);
@@ -1915,7 +1917,9 @@
free_dma(p->dma);
if (p->irq != PARPORT_IRQ_NONE)
free_irq(p->irq, p);
- release_region(p->base, p->size);
+ release_region(p->base, 3);
+ if (p->size > 3);
+ release_region(p->base + 3, p->size - 3);
if (p->modes & PARPORT_MODE_ECP)
release_region(p->base_hi, 3);
parport_proc_unregister(p);
-
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/