From owner-freebsd-new-bus Tue Aug 27 13:36:48 2002 Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B80737B400 for ; Tue, 27 Aug 2002 13:36:44 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id C12BF43E72 for ; Tue, 27 Aug 2002 13:36:43 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 16847 invoked from network); 27 Aug 2002 20:36:43 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Aug 2002 20:36:43 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g7RKaeBQ039798 for ; Tue, 27 Aug 2002 16:36:40 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 27 Aug 2002 16:36:43 -0400 (EDT) From: John Baldwin To: new-bus@FreeBSD.org Subject: Fixing ISA device probing Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The original reason for bringing this up: ACPI currently bogusly attaches ACPI-enumerated ISA devices to acpi0 instead of to an ACPI-aware ISA bus driver. After talking some with Warner offline we have come up with the following rough ideas and possible layout. This would probably be a big change but hopefully it can be broken down into a few chunks. Currently we have several types of ISA devices: - Devices enumerated by the BIOS. Currently we have two types: those enumerated by ACPI and those by the PNPBIOS. These two sets are mutually exclusive. - PnP ISA devices. - ISA devices that only the user can tell us about (currently they can use hints to tell us). All ISA busses can have the last two devices, but the first set of devices are not always present. Thus it makes sense to possibly have 3 ISA bus drivers: - A basic ISA bus which supports PnP ISA devices and hint devices (mostly what we have now but without PnPBIOS support) - A PNPBIOS ISA bus which inherits from the basic ISA bus with the addition of PNPBIOS devices. - An ACPI ISA bus which inherits from the basic ISA bus with the addition of ACPI-enumerated ISA devices. This in itself is not but so hard and perhaps we could do this as the first step. However, there are some annoying inconsistencies with our current hints mechanism. Namely, we don't support "merging" a hints device with an otherwise-enumerated device. For example, if I just have a single hint for sio0: hint.sio.0.flags=0x10 That flag should get applied to the sio0 enumerated by either ACPI or the PNPBIOS. How can this be done? Well, first of all, we can determine whether a hint device can be merged with a BIOS-enumerated ISA device by checking the resources. To do this, we can check if the resources of the hint device form a subset of the resources in the enumerated device? This should be slightly stronger than just being a strict subset, however. For example, in the case of I/O ports the port in the hint should match the first port in one of the port resources for the PnP device. If a resource is not specified in the hint then it would match the first such device. Thus, if I give the port associated with com2 in addition to the 'sio0' hint above as an sio0 port, then com2 should be attached as com2 and we should merge the sio0 hint device with the com2 PNPBIOS device. Next, if the resources do match, we can do a test probe. This is because hint devices are hardwired to a driver and unit as opposed to BIOS-enumerated devices which are not. For the test probe, we assign the BIOS-enumerated device the driver and unit of the hint device and then do our probe. If the probe succeeds we toss the hint device. If it fails, then we change the BIOS-enumerated device back to not having a driver yet and continue. We would then iterate through each hint device trying to match it against any BIOS-enumerated devices that have not already done a successful probe. Once that is done, the bus driver would probe any remaining unprobed BIOS-enumerated devices and then let the generic ISA bus handle remaining PnP and hint devices. This would give us hardwiring of devices as well as supplying hints to BIOS-enumerated devices. Note that I haven't covered applying those to PnP devices not enumerated by the BIOS. Presumably, the generic ISA bus could attempt to do its own hint device merging where appropriate. Unfortunately, we would need to fix a few things before taking this second step. Specifically, device probes need to be just that: probes. attach routines should not require that special magic be done in probe for them to work properly. For example, to avoid the "sensitive driver" problem we currently have, when an ISA device probes, if the device being probed has an HID, then the probe routine should only check to see if the HID matches or not and then return. This would allow the test probes during hint-merging for BIOS-enumerated or PNP devices to work w/o having negative side effects. Comments? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message