Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 08 Oct 1999 17:57:54 -0600
From:      Warner Losh <imp@village.org>
To:        new-bus@freebsd.org
Subject:   Question about self identifying devices
Message-ID:  <199910082357.RAA70840@harmony.village.org>

next in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910082357.RAA70840>