i posted this to the scsi list - but nobody answered - maybe
someone here can help me ...
a few days ago i postet here (and before at the scsi list) patches
to get rid of the "Bad boy: i91u (at 0xc4a2b602) called us without a
dev_id!" thing in the current (2.3.99-pre) kernels which seems to
have gone into 2.2.16-pre3 ... now i have made the same with the
other initio driver (a100u2w) and while doing this i did not
really understand how the ressource allocation woks here ...
in the _detect routine they both call request_irq and request_region
but they never free them on module unload (there is no _release
funtion calling fre_irq or release_region) ... is this done im-
plicitley by the module unload code ? (i don't think so and thus
added a simple _release function to them like in most other scsi
drivers)
after doing this everything still ran fine :-) ... only i always
get "Trying to free nonexistent resource <6200-62fe>" now on the try
to unload the module ... after looking a bit deeper i noticed that
due to /proc/ioports the regions are already mapped before i even
load the initio module (calling request_region in it) - thus the
request fails - so the resource is not mapped that way and i can't
unmap it using release_region - so far i think i understand what
exactly happens here
the question remaining now for me is: what is the proper way of
io and irq ressource management in linux now ? - does it somehow
map all the pci ressources by itself or why are the ports already
maped ? - can anyone please explain me a bit how all this would
look like in a "perfect" driver ? (or point me to some doc about
this ?)
one more quite small question: is the 0x100 correct in the
request_region call (i would assume 0xff) of both initio
drivers ? (ini9100u.c and inia100.c) - i would assume
0xff ...
a lot of thanks in advance
t
p.s.: here are the patches (2) i used for all this for the a100
driver - similar patches apply for the i9100u driver ... if i
understand all this (and the patches are ok) - i'll post
a final patch here again here later ...
1. give a dev_id to the a100u2w request_irq call
--- inia100.c.org Thu May 18 14:42:53 2000
+++ inia100.c Thu May 18 13:44:29 2000
@@ -411,28 +411,28 @@
/* Initial orc chip */
switch (i) {
case 0:
- ok = request_irq(pHCB->HCS_Intr, inia100_intr0, SA_INTERRUPT | SA_SHIRQ, "inia100", NULL);
+ ok = request_irq(pHCB->HCS_Intr, inia100_intr0, SA_INTERRUPT | SA_SHIRQ, "inia100", hreg);
break;
case 1:
- ok = request_irq(pHCB->HCS_Intr, inia100_intr1, SA_INTERRUPT | SA_SHIRQ, "inia100", NULL);
+ ok = request_irq(pHCB->HCS_Intr, inia100_intr1, SA_INTERRUPT | SA_SHIRQ, "inia100", hreg);
break;
case 2:
- ok = request_irq(pHCB->HCS_Intr, inia100_intr2, SA_INTERRUPT | SA_SHIRQ, "inia100", NULL);
+ ok = request_irq(pHCB->HCS_Intr, inia100_intr2, SA_INTERRUPT | SA_SHIRQ, "inia100", hreg);
break;
case 3:
- ok = request_irq(pHCB->HCS_Intr, inia100_intr3, SA_INTERRUPT | SA_SHIRQ, "inia100", NULL);
+ ok = request_irq(pHCB->HCS_Intr, inia100_intr3, SA_INTERRUPT | SA_SHIRQ, "inia100", hreg);
break;
case 4:
- ok = request_irq(pHCB->HCS_Intr, inia100_intr4, SA_INTERRUPT | SA_SHIRQ, "inia100", NULL);
+ ok = request_irq(pHCB->HCS_Intr, inia100_intr4, SA_INTERRUPT | SA_SHIRQ, "inia100", hreg);
break;
case 5:
- ok = request_irq(pHCB->HCS_Intr, inia100_intr5, SA_INTERRUPT | SA_SHIRQ, "inia100", NULL);
+ ok = request_irq(pHCB->HCS_Intr, inia100_intr5, SA_INTERRUPT | SA_SHIRQ, "inia100", hreg);
break;
case 6:
- ok = request_irq(pHCB->HCS_Intr, inia100_intr6, SA_INTERRUPT | SA_SHIRQ, "inia100", NULL);
+ ok = request_irq(pHCB->HCS_Intr, inia100_intr6, SA_INTERRUPT | SA_SHIRQ, "inia100", hreg);
break;
case 7:
- ok = request_irq(pHCB->HCS_Intr, inia100_intr7, SA_INTERRUPT | SA_SHIRQ, "inia100", NULL);
+ ok = request_irq(pHCB->HCS_Intr, inia100_intr7, SA_INTERRUPT | SA_SHIRQ, "inia100", hreg);
break;
default:
inia100_panic("inia100: Too many host adapters\n");
2. the simple _release function for the a100 driver
--- inia100.c.org Thu May 18 14:42:53 2000
+++ inia100.c Thu May 18 13:44:29 2000
@@ -784,5 +784,20 @@
printk("\ninia100_panic: %s\n", msg);
panic("inia100 panic");
}
+
+#ifdef MODULE
+/*
+ * inia100_release()
+ *
+ * Release resources allocated for a single initio a100 adapter.
+ */
+int inia100_release(struct Scsi_Host *hreg)
+{
+ free_irq(hreg->irq, hreg);
+ release_region(hreg->io_port, hreg->n_io_port);
+ return 0;
+}
+#endif
/*#include "inia100scsi.c" */
--- inia100.h.org Thu May 18 14:43:55 2000
+++ inia100.h Thu May 18 13:09:44 2000
@@ -74,6 +74,9 @@
extern int inia100_command(Scsi_Cmnd *);
extern int inia100_queue(Scsi_Cmnd *, void (*done) (Scsi_Cmnd *));
extern int inia100_abort(Scsi_Cmnd *);
+#ifdef MODULE
+extern int inia100_release(struct Scsi_Host *);
+#endif
extern int inia100_reset(Scsi_Cmnd *, unsigned int);
extern int inia100_biosparam(Scsi_Disk *, kdev_t, int *); /*for linux v2.0 */
@@ -87,7 +90,7 @@
proc_info: NULL, \
name: inia100_REVID, \
detect: inia100_detect, \
- release: NULL, \
+ release: inia100_release, \
info: NULL, \
command: inia100_command, \
queuecommand: inia100_queue, \
-- thomas.graichen@innominate.de innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg- 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/
- 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/
This archive was generated by hypermail 2b29 : Fri May 19 2000 - 14:18:10 EDT