From owner-freebsd-new-bus Fri Oct 8 16:57:58 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id CB57314FFC for ; Fri, 8 Oct 1999 16:57:55 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id RAA22211 for ; Fri, 8 Oct 1999 17:57:57 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id RAA70840 for ; Fri, 8 Oct 1999 17:57:54 -0600 (MDT) Message-Id: <199910082357.RAA70840@harmony.village.org> To: new-bus@freebsd.org Subject: Question about self identifying devices Date: Fri, 08 Oct 1999 17:57:54 -0600 From: Warner Losh Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a question about self identifying devices. It is for a custom driver for some hardware that we have at work, but I'll describe it in terms of something in the tree already since the problems are identical. Consider the aha driver. There are 6 locations that the aha driver can map itself into. Right now the probe code has a loop over these addresses plus some self-stepping protection. However, this uglifyies the probe code, so I'm tempted to add code like the following to aha_isa.c: static void aha_isa_identify(driver_t *driver, device_t parent) { device_t child; int i; int addr; int ports[] = { 0x330, 0x334, 0x230, 0x234, 0x130, 0x134 }; int nports = sizeof(ports) / sizeof(ports[0]); for (i = 0; i < nports; i++) { addr = ports[i]; child = BUS_ADD_CHILD(parent, 0, "aha", 0); if (child == NULL) panic("aha_identify"); ISA_SET_RESOURCE(parent, child, SYS_RES_IOPORT, i, addr, AHA_NREG); } } However, there are some problems with this. If I make aha a loadable and unloadable module this creates problems. The first time it is loaded, things appears to be good, until, however, probe happens. When the probe happens, I get something like: aha3: <...> panic: resource_list_alloc: resource entry is busy Debugger("panic") Stopped at Debugger+0x37: movl $0,in_Debugger which seems odd to me. What does this mean? Any idea on how to debug this? If I take out the ISA_SET_RESOURCE from the above, then I don't get the panic. ddb doesn't seem to grok the loaded drivers since I get an address of end+....... on the stack traceback. Second, I suspect that this is too odd for most people. They would get aha3 for a card wired to 0x234 rather than the aha0 they have now. Also, it wouldn't be possible to hardwire them. On the plus side, if I have two aha cards in my system and I load the driver I get to see BOTH of them (right now, you'd only see the first one, which is why I got looking into this problem). I'm not sure what a good thing would be here, short of "prerunning" probe. Third, if I load, unload, load the driver, the previous instances of the aha0..aha5 are still around, so I get aha6..11 as well as aha0..5 and the probes for both aha0 and aha6 seem to succeed. Is there a good way to get rid of the children when I unload? Or should I check to make sure that the aha0 is there first... Comments? Warner P.S. This is for a measurement system where we have n foo-measurement cards. We want to load the driver rather than statically link it in. In the past, we constructed an array of isa_driver which we iterate over in the KLD_LOAD case. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message