From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 21 16:06:34 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D17716A435 for ; Fri, 21 Oct 2005 16:06:34 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9918743D45 for ; Fri, 21 Oct 2005 16:06:33 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9LG5Bw8026150; Fri, 21 Oct 2005 10:05:12 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 21 Oct 2005 10:06:35 -0600 (MDT) Message-Id: <20051021.100635.115989045.imp@bsdimp.com> To: frank@pinky.sax.de From: "M. Warner Losh" In-Reply-To: <200510210835.j9L8Zn2P001846@pinky.frank-behrens.de> References: <200510210835.j9L8Zn2P001846@pinky.frank-behrens.de> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 21 Oct 2005 10:05:12 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: How disable attachment of sio(4) driver to device? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 16:06:34 -0000 In message: <200510210835.j9L8Zn2P001846@pinky.frank-behrens.de> "Frank Behrens" writes: : I want to use the second port with my driver. I had no luck with : hint.sio.1.disabled="1", but hint.sio.1.flags="0x40" : gave me the desired result: : sio1: reserved for low-level i/o Allocate the resources it uses, and sio can't probe. : One partly working workaround I found is to patch the sio driver. If : it does in DEVICE_PROBE(9) not return (0), but the value : BUS_PROBE_DEFAULT, then my driver has a chance to attach. : If my driver does not attach or another driver is loaded, the sio(4) : attaches again and I have lost. Then I see only a reboot as solution : to try my driver again. Right. There's a weakness in the current scheme in that one can't rebid a device. I've been working on some patches for that. That's the real way to solve this problem. Another "soltution" is to not have sio in your kernel while you are debugging your driver. Another solution would be to have your driver use the tty layer instead of banging the hardware directly, if that is compatible with the goals of your driver. This solution isn't in quotes because for some class of devices (say a keyboard driver for a sun or apple newton keyboard that does serial), it might be the right one. : I think I did miss some important information, e.g. I could not find : how the associations between PCI selectors (pciconf(8)) and device : numers are made and what to insert in device.hints to modify this : associations. There's no way to tie the plug and play location to a device instance at this time. Warner