Date: Mon, 6 Feb 1995 11:57:44 -0800 (PST) From: julian@tfs.com (Julian Elischer) To: steve2@genesis.nred.ma.us (Steve Gerakines) Cc: freebsd-hackers@FreeBSD.org Subject: Re: FIX FOR CACHE/DMA RANGE PROBLEMS Message-ID: <m0rbZZA-0003vyC@TFS.COM> In-Reply-To: <199502061440.GAA20680@genesis.nred.ma.us> from "Steve Gerakines" at Feb 6, 95 06:40:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
I have working eisa probe code in my home directory in freefall, but it had one problem.... it couldn't successfully replace the IRQ with that found.... this has now been fixed apparently in the drivers, so maybe it should be looked at again This code first looks at the EISA slots then it adds an entry for itself (as 'found') to the isa lists, so that ISA devices that use the same ports will not try probe.. .. julian > > This is basically what I'm saying. To take it one step further however, I > don't think any eisa device should need to be hardcoded in config. There > should be one routine (in i386/eisa/eisa.c perhaps? :-)) that scans the slots > and retrieves board id's. If there was a table of EISA board id's and their > associated probe()/attach() routines, eisa.c could look up the id and > automatically config EISA devices. An EISA attach routine would be passed > in the slot the board was found, and would be smart enough to retrieve and > return the particular board settings. This way when a probe or attach > routine is called it's known in advance that a card really does exist there. > This takes the burden of scanning slots out of each driver and puts it in > a central place. > > - Steve > steve2@genesis.nred.ma.us >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0rbZZA-0003vyC>