From owner-freebsd-stable@FreeBSD.ORG Wed Jun 2 16:26:46 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FCE016A4CF for ; Wed, 2 Jun 2004 16:26:46 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45F3343D46 for ; Wed, 2 Jun 2004 16:26:45 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i52NNGRF036424; Wed, 2 Jun 2004 17:23:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 02 Jun 2004 17:23:12 -0600 (MDT) Message-Id: <20040602.172312.98616592.imp@bsdimp.com> To: joe@zircon.seattle.wa.us From: "M. Warner Losh" In-Reply-To: <1085764038.485.71.camel@zircon> References: <1085610184.3232.250.camel@zircon> <20040528.090131.17267826.imp@bsdimp.com> <1085764038.485.71.camel@zircon> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: stable@freebsd.org Subject: Re: Thanks for All the Help X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 23:26:46 -0000 Sorry for the late reply. My weekend was a little more chaotic than I'd planned. Please accept my appologies. I'd like to point you to the handbook information first: http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/isa-driver.html Which has some background on the whole process, and walks you through it. I just read it again, and here are my -stable relative comments. Section 14.8 talks about the probe routine. Here are my comments on it: You don't need to worry about PNP, per se, but you do need to filter out the pnp devices from patching your device in your probe routine. This is typically done like so: static int sn_isa_probe (device_t dev) { if (isa_get_logicalid(dev)) /* skip PnP probes */ return (ENXIO); if (sn_probe(dev, 0) != 0) return (ENXIO); return (0); } the above code is from the sn driver, which has a fairly generic probe routine that's used for both ISA and PCMCIA cards. You should ignore the section that talks about looking at all the possible device locations. This is no longer done in the probe routine, but in the related identify routine. But only for self identifying devices (which are fairly rare if they aren't PNP enumerated). Typically, the simple, non-pnp devices are statically linked into the kernel and you get the resources from the kernel config line. All resources that you allocate in the probe routine must be released before you exit the probe routine. I tend to use the methods described near the end of section 14.8 to have one routine that allocates resources and one that frees all resources. Section 14.9 is also fair description of how the attach routine should be written. Again, a generic resource allocation and freeing routine will save time here. Avoid use of rman_get_virtual since it makes it harder to user your device in a PAE kernel (use busdma instead if your ISA device supports DMA). As for the glue for the driver, you can pretty much take most of it from section 14.2 which gives the lowdown on the boilerplate stuff that's required. Chances are excellent that you won't have to worry about shutdown, suspend or resume. If you don't want to make your driver loadable, there's little to no harm in 4.x to not having a detach routine. All in all, the chapter has all the information you need. I'd have organized it a little differently than it is, but a careful reading should help get you going. The sn driver, all things considered, isn't a horrible driver to look at for these things. It isn't perfect, and there are people that can find faults with it, but it would serve as a good guide to writing isa drivers. ed and ep are well maintained, but suffer too much from being really popular hardware and have a lot of distracting warts, as well as vestiges of past APIs here and there that will be confusing. Warner