From owner-freebsd-hackers Mon Oct 13 22:14:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA22887 for hackers-outgoing; Mon, 13 Oct 1997 22:14:40 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA22859 for ; Mon, 13 Oct 1997 22:14:32 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id OAA00799; Tue, 14 Oct 1997 14:40:56 +0930 (CST) Message-Id: <199710140510.OAA00799@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Fred L. Templin" cc: Mike Smith , freebsd-hackers@freebsd.org Subject: Re: pccard driver questions (FreeBSD 2.2.2-RELEASE + PAO-970616) In-reply-to: Your message of "Mon, 13 Oct 1997 10:39:49 MST." <199710131739.KAA03124@grayling.erg.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Oct 1997 14:40:56 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > I'm not sure I understand why you want to manipulate the per-slot > > mappings. The card offers a window of some fixed size, which you can > > relocate over its internal address space, correct? If this is the > > case, then you only map this window once, and subsequently fiddle the > > cards internals to shift the window around. > > The problem is that the card really doesn't have any internals to shift > around. It presents itself as a contiguous chunk of approx. 96KB of > common memory and expects the host to write data and commands into the > correct locations. Is there any other way to handle this besides re- > mapping the 4KB window that gets set up when the card is inserted? You could map a larger window; that'd certainly be better. TBH I haven't checked to see if there is a limitation that would prevent you from having a 96kB window for your card. > > Note that it's possible (not having checked the code) that the memory > > mapped for the card is revoked before the removal hook is called (it > > shouldn't be, but it might). If that's the case, polling as above may > > cause a kernel fault, and the unmapping will have to be fixed. > > This is what concerns me; de-referencing bogus pointers while manipulating > the per-slot window mappings in my driver after the slot driver disappears > and takes it's data structures with it. This concern goes away if there is > some other way for me to program my card besides fiddling with the window > mapping, or if some mutual exclusion can be provided between the slot > driver and my driver while dealing with the per-slot data structures. > Any ideas on either approach would be welcome... Well, the mapping isn't bogus until it's revoked by disable_slot(), and it's not revoked until _after_ the driver unload function is called. So you are guaranteed notification (at splhigh()) of card removal before your mapping is revoked. mike