From owner-freebsd-hackers  Sat Sep 30 02:37:09 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id CAA24016
          for hackers-outgoing; Sat, 30 Sep 1995 02:37:09 -0700
Received: from ref.tfs.com (ref.tfs.com [140.145.254.251])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA24007
          for <hackers@freebsd.org>; Sat, 30 Sep 1995 02:37:06 -0700
Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id CAA18581 for hackers@freebsd.org; Sat, 30 Sep 1995 02:36:52 -0700
From: Julian Elischer <julian@ref.tfs.com>
Message-Id: <199509300936.CAA18581@ref.tfs.com>
Subject: correctness of isa.c
To: hackers@freebsd.org
Date: Sat, 30 Sep 1995 02:36:51 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1673      
Sender: owner-hackers@freebsd.org
Precedence: bulk

 in isa_device.h,
in struct isa_device{}
one field , is defined as:
caddr_t id_maddr;       /* physical i/o memory address on bus (if any)*/

ok so this is the Physical address of ram on the device..

so why does isa.c pass it into the device as:

        if (!reconfig && isdp->id_maddr) {
                isdp->id_maddr -= 0xa0000; /* XXX should be a define */
                isdp->id_maddr += atdevbase;

which is the kvm mapped address of it..
BUT ONLY IF THE DEVICE IS in the 640K-1MB hole!

I have a device at 2GB
needless to say, I need to 'undo' this mess when
I'm probed, to find my original address..

sure it's a nice idea to do it in one place, but 
it doesn't cover all bases..

then to add insult to injury:

further down..
we see.
           if (isdp->id_maddr)
                   printf(" maddr 0x%lx", kvtop(isdp->id_maddr));

where the field is Assumed to hold a kernel virtual address..

naturally, 2GB+addevbase-0xa0000 gives a rather strange answer..
and what if I didn't want to map that memory all at once,
but use it page by page?
I'd have to zero this field, but then I wouldn't get a message
about it..

grrrrr

If I were to 'fix' this for all our drivers,
does anyone here see a really important reason for this field
to hold physical and virtual addresses at different times?
I have a pass over all drivers coming up to add devfs stuff..
I could add this to the list of things to fix..
not that many drivers have shared memory, and with frame buffers mapped
into high memory becoing more common, this kludge should go..
(also while we're about it, why is id_irq a bitfield?
it's almost believable, but is there a really good reason?)

julian