From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 20:41:25 2008 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F029516A417; Wed, 2 Jan 2008 20:41:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 91C2213C457; Wed, 2 Jan 2008 20:41:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id m02Ke9gt072736; Wed, 2 Jan 2008 13:40:09 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 02 Jan 2008 13:40:33 -0700 (MST) Message-Id: <20080102.134033.-672663610.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200801021453.02931.jhb@freebsd.org> References: <200801021303.39518.jhb@freebsd.org> <0E7F7277-75F4-4A5A-924D-97C0C9D940CD@mac.com> <200801021453.02931.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@FreeBSD.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 20:41:26 -0000 In message: <200801021453.02931.jhb@freebsd.org> John Baldwin writes: : On Wednesday 02 January 2008 02:14:55 pm Marcel Moolenaar wrote: : > : > On Jan 2, 2008, at 10:03 AM, John Baldwin wrote: : > : > > Agreed, and device.FOO would create an unknownX device (much like : > > unprobed : > > PNPBIOS or ACPI-enumerated devices) with a set of properties (if the : > > bus impl : > > uses properties to create devices and doesn't use them purely as : > > additional : > > metadata). For example, I actually figured that the default : > > device.hints type : > > stuff for COM1 would look like this: : > > : > > device.COM1.at="isa" : > > device.COM1.port="0x3f8-0x3ff" : > > device.COM1.irq=4 : > > device.COM1.pnpid="PNP0500" : > : > BTW: I like the port range. : : I hate that abuot the current hints actually where drives hardcode things like : IO_COMSIZE. I really would like the enumeration data that is provided not by : the firmware to look like something that comes from firmware, on which we : seem to agree. We're all in agreement here then. I think the entire resource (not just range) should be accepted here. Eg: hint.fdc.0.port="0x3f2-0x3f3,0x3f4-0x3f5,0x3f7" or whatever your favored syntax is for the left hand side of the = sign. I'd prefer this over a portsz key. It is useful for many instances of this problem, not just the odd-ball floppy drive. Note: The above is a little more complicated than what a user would enter, but many BIOS tables are constructed that way. Also, I'd like to keep the 'You have this resource' command different than the 'Bind me to the device that has this resource' command. So : FOO { : resources { : irq { : 0=4 : } : ioport { : 1=0xa-0xb : } : } : at="blah" : } : We could also call 'at', 'location' perhaps. I think this still confuses things and is a cumbersome syntax. FOO { resources { irq(0)=4 } location { ioport=0xa-0xb _HID="COMA" } driver="sio" unit=2 } Would be much better. we could then have wildcard entries like so that are unnamed: { location { _HID="PNP0501" bus="acpi" } driver="uart" baud=115200 } { location { vendor=0x3451 device=0x0001 bus="pci" } driver="sio" baud=1200 } if one wanted to universally use uart for all serial ports. This also mirrors the pnpinfo that the ACPI bus provides and the PCI bus provides. It would easily allow one to look at the devinfo -v output and know how to bind a driver to a hunk of hardware (generically). It would also allow us to say: { location { bus="pci3" slot=31 function=1 // or at=pci3.31.1 // or at=pci0.3.31.1 including the pci domain } override { vendor=0x3451 device=0x0001 } } if we wanted to integrate into this system the strong desire that people have expressed for being able to say 'treat device X as if it were a Y'. Warner