From owner-freebsd-current Sun Jun 25 17:11:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA13415 for current-outgoing; Sun, 25 Jun 1995 17:11:02 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA13408 for ; Sun, 25 Jun 1995 17:10:50 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id KAA10740; Mon, 26 Jun 1995 10:09:35 +1000 Date: Mon, 26 Jun 1995 10:09:35 +1000 From: Bruce Evans Message-Id: <199506260009.KAA10740@godzilla.zeta.org.au> To: bde@zeta.org.au, peter@haywire.DIALix.COM Subject: Re: i386/563: isa conflict detection cannot handle ioaddr 0x0 Cc: current@freebsd.org Sender: current-owner@freebsd.org Precedence: bulk >> 0 is a valid io address. I think the bug is actually that config >> generates address 0 instead of an out of bounds address for devices that >> don't have an io address. The out of bounds address should probably be >But isn't the DMA1 controller at IO address 0x0 -> 0x1F? IMHO, that >makes it just about as invalid a choice for an expansion card as one can >get.. :-) The DMA registers should be in a device or something so that they get conflict-checked. Anyway, config is supposed to somewhat machine-independent and shouldn't presume anything about the address space. I think 0 is considered free mainly because it is a null pointer constant. config should also presume less about the representation of addresses. It stores memory addresses in an int and port addresses in a (char *). Addresses should be represented by u_long's or u_quad_t's. >Hmm. There appears to be a sort-of convention with the existing code.. >if you dont specify a maddr, config sets it to zero. isa.c knows that >"maddr 0" is disabled. Yes. I guess the no-maddr case got fixed because it is very common. >Same goes for the irq - it appears to be set to 0 if it's not specified >in the config line, and the isa code disables conflict testing. As far >as I can see, there _is_ an IRQ0 in the system (at least there are >vectors in isa.c), but I think it's permanently wired to a timer or >something. IRQn is actually (1 << n) so 0 is special. This is another thing that is done wrong. IRQn should be n and irq numbers -1 and -2 special. I think this is fixed in NetBSD. >On the other hand, drq appears to be -1 for being "not specified", to blow >away my argument above. :-) DRQn is n so there is no alternative to -1 being special. >My preference would be that "port ?" is different to "" (none). Indeed, Yes, that's what the -1 and -2 are for. Config, isa.c and drivers would have to be more careful about sign extension if they used u_longs like I said to above. Someone once made id_iobase a u_short and broke the `id_iobase < 0' test in lpt.c. >For now, I'd plead for making the io port conflict detection consistant >with the memory address conflict detection.. ie: "0" == no setting. >It'll at least make the current code that's "out there" work. OK. Bruce