From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 22 16:33:44 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 3041A16A41F; Sat, 22 Oct 2005 16:33:44 +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 B7D5E43D45; Sat, 22 Oct 2005 16:33:43 +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 j9MGVIkK041074; Sat, 22 Oct 2005 10:31:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 22 Oct 2005 10:32:42 -0600 (MDT) Message-Id: <20051022.103242.98606517.imp@bsdimp.com> To: frank@pinky.sax.de From: "M. Warner Losh" In-Reply-To: <200510221516.j9MFGnqT026691@pinky.frank-behrens.de> References: <200510211216.37814.jhb@freebsd.org> <20051021.113739.32720831.imp@bsdimp.com> <200510221516.j9MFGnqT026691@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]); Sat, 22 Oct 2005 10:31:18 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.ORG, jhb@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: Sat, 22 Oct 2005 16:33:44 -0000 In message: <200510221516.j9MFGnqT026691@pinky.frank-behrens.de> "Frank Behrens" writes: : > 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. : : Hm, this looks even more complicated and has more overhead. To show : shortly my requirements: The protocol is for an eib driver, (further : information on http://www.sax.de/~frank/eib4bsd/), it uses 9600 baud : on serial line. If the PC wants to send a telegram it resets RTS and : has to poll CTS. If CTS is active the transmission of one byte is : possible. If the last bit is sent (transceiver shift empty!) the PC : sets RTS and waits until CTS is inactive. Then a new handshake can : start and a transmission of about 30 bytes must be finished in 130 : ms. IMHO this can be handled only in an interrupt routine with low : overhead. That's only about a 25% duty cycle on the line. You might look at the uart driver to see if you can hook into it in such a way as to get the notification of these events via interrupt. I thought that when the control bits changed there was an interrupt. : M. Warner Losh wrote on 21 Oct 2005 11:37: : > I'd like to be able to say that sio0 is at handle=\_SB_.PCI0.PX40.UAR2 : > rather than some arbitrary address. Or that bge1 is at : > : > bge0 pnpinfo vendor=0x14e4 device=0x16a6 subvendor=0x14e4 subdevice=0x8009 class=0x020000 at slot=3 function=0 handle=\_SB_.PCI0.G0PA.LAN0 : > miibus0 : > brgphy0 pnpinfo oui=0x818 model=0x16 rev=0x2 at phyno=1 : > bge1 pnpinfo vendor=0x14e4 device=0x16a6 subvendor=0x14e4 subdevice=0x8009 class=0x020000 at slot=4 function=0 handle=\_SB_.PCI0.G0PA.LAN1 : > : > either at pci2.4.0 *OR* at handle=\_SB_.PCI0.G0PA.LAN1 (or even : > handle=LAN1). So there'd need to be some kind of bus specific mapping : > function that would say true or false if a given device_t on that bus : > matched the string presented. : : For my driver I made already a sort of this. Part of my probe routine : is : if (resource_string_value(EIBNAME, 0, "at", &hintBus)) : return (ENXIO); : if (strcmp(hintBus, "pci")) : return (ENXIO); : : if (resource_int_value(EIBNAME, 0, "bus", &hint) == 0 && : pci_get_bus(device) != hint) { : return (ENXIO); : } : if (resource_int_value(EIBNAME, 0, "slot", &hint) == 0 && : pci_get_slot(device) != hint) { : return (ENXIO); : } : if (resource_int_value(EIBNAME, 0, "function", &hint) == 0 && : pci_get_function(device) != hint) { : return (ENXIO); : } There's problems doing this in the general case. I tried doing something similar to this a few years back, and discovered that doing it in the driver caused problems. Specifically, if another device is before you in the probe order, that device might snag the hinted device's location. With most drivers returning BUS_PROBE_DEFAULT these days, this is effectively masked. It is also tedious and error-prone to specificy things this way... it will likely be completely adequate for most of your needs, however... : So my conclusion is: : 2. I will create a PR to change the sio(4) driver, that it returns : BUS_PROBE_DEFAULT instead of BUS_PROBE_SPECIFIC. : Then further patching is not necessary. I believe that's correct. Warner