Date: Tue, 14 Oct 1997 14:40:56 +0930 From: Mike Smith <mike@smith.net.au> To: "Fred L. Templin" <templin@erg.sri.com> Cc: Mike Smith <mike@smith.net.au>, freebsd-hackers@freebsd.org Subject: Re: pccard driver questions (FreeBSD 2.2.2-RELEASE + PAO-970616) Message-ID: <199710140510.OAA00799@word.smith.net.au> In-Reply-To: Your message of "Mon, 13 Oct 1997 10:39:49 MST." <199710131739.KAA03124@grayling.erg.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710140510.OAA00799>