From owner-freebsd-current Sat Sep 2 19:25:37 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id TAA22732 for current-outgoing; Sat, 2 Sep 1995 19:25:37 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id TAA22725 for ; Sat, 2 Sep 1995 19:25:26 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id TAA16173; Sat, 2 Sep 1995 19:24:34 -0700 From: "Rodney W. Grimes" Message-Id: <199509030224.TAA16173@gndrsh.aac.dev.com> Subject: Re: Getting around conflicts for a driver w/out base address To: deischen@iworks.InterWorks.org (Daniel M. Eischen) Date: Sat, 2 Sep 1995 19:24:33 -0700 (PDT) Cc: FreeBSD-current@FreeBSD.Org (FreeBSD current) In-Reply-To: <9509030032.AA25745@iworks.InterWorks.org> from "Daniel M. Eischen" at Sep 2, 95 07:32:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3297 Sender: current-owner@FreeBSD.Org Precedence: bulk > > > Hi, Hello. > > I've written an driver for an ISA device that does not have an IO base > address; it is strictly a memory mapped device. What is the proper method > of informing the isa probes to not check the IO base address (id_iobase in > isa_device) for conflicts with other drivers? The opposite holds true also; > when checking other ISA devices for IO base address conflicts, we want to > avoid that check with this device. Please post this message to -current, I know others have worked in this area since myself, and I am pretty sure Bruce has either changed this, or is going to change this, or atleast mumbled about it a few times. > I've tried the following configurations to no avail: > > device mib0 at isa? port ? irq 10 ... > device mib0 at isa? irq 10 ... # no port > > Both of the above conflict with either the lpt or the ahc drivers. Hum, yea, I think config(8) is doing the wrong thing with null ``port'' specifications. What does the ../../compile/KERNEL/ioconf.c file look like? [Just the applicable mib0, lpt and ahc lines.] > What I ended up doing was to assign it at an unused port address (0x350) > and return 1 for the probe function. That will work as a temporary work around until the correct fix is done. > I took a look at the isa.c code, and saw your comments in there regarding > the NPX driver. It looks like you return a value of -1 in the probe > routine (which ends up getting placed in id_alive) to quiet the IO base > address reporting. It also looks like you omit the IO base address checks > when checking for conflicts after probing other drivers. That code has been hacked on by a few dozen folks since I wrote it, it now looks quite different, and I have not looked at it in some time :-(. The -1 thing was mine, and yes it added to allow a driver to report ``I use no I/O ports'', so as long as no one else has grabbed -1 for some other purpose your proposed define makes perfect since. Not sure that isa_device is the right place for it though, this is applicable to _all_ drivers. > I can't test this out until I'm at work Tuesday, but this looks like what > I want to do. Given that, what about placing a define in isa_device.h > for this: > > /* > * Drivers that do not have IO base addresses should return this > * in the probe routine. > */ > #define ISA_NO_IOBASE -1 > > or something like that. That way it becomes apparent what a driver should > do. Seems reasonable but I would like to see this passed by a few people, and not so sure about the location of the define or the need for ISA_ in the name of it, this is also applicable to EISA and MCA devices. > > I was going to post this to the -hackers list, but after I saw your comments > regarding the NPX driver in isa.c, I thought I'd ask you first without taking > up mailing list bandwidth. > > If this really does belong on the mailing list, then I apologize in advance. No problem in passing it by people first, Infact I am just goint to add -current to the cc: list and let my reply put this thread on the list :-). > Dan Eischen > deischen@iworks.InterWorks.org -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD