From owner-freebsd-new-bus Fri Aug 30 22:53: 1 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 A7CB237B400 for ; Fri, 30 Aug 2002 22:52:58 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA83743E65 for ; Fri, 30 Aug 2002 22:52:31 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7V5qU2F049473 for ; Fri, 30 Aug 2002 23:52:30 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 30 Aug 2002 23:52:24 -0600 (MDT) Message-Id: <20020830.235224.34542516.imp@bsdimp.com> To: new-bus@FreeBSD.org Subject: Re: ISA bus notes From: "M. Warner Losh" In-Reply-To: References: <20020830.220723.10970697.imp@bsdimp.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 In message: John Baldwin writes: : Well, I think you are looking at it not quite from an OOP perspective. : :) Try using the same model of overriding bus drivers that I use : with ACPI and the PCI bus. Thus, instead of having the system try : and know which kind of ISA bus to attach, you have three drivers for : "isa": That's what the probe routines are for (oh, I see below you grok that too). The system doesn't really know. I just wrote the if to show the order. I wrote the driver names the way I did to make sure that they were separate drivers and we didn't try to cobble it all into the isa driver. : - acpi_isa (called "isa" though) whose probe routine only : succeeds if it can read it's handle via ivars on itself. In : all ACPI systems that I know of, we can handle this case fairly : easily by providing an ACPI PCI-ISA bridge driver that adds ivar : support for the child bus device like the ACPI PCI bus driver : does; probe routine returns 0 on success : - pnp_isa (again, "isa") whose probe routine only succeeds if : PNPBIOS is detected. This probe routine can return -100 or some : such. : - isa (again, "isa") whose probe routine pretty much always succeeds : and returns -1000 or some such Yup. We're on the same page here. Good detail catch. : This way, ISA busses become the right "flavor" of an ISA bus via : normal probe/attach methods (i.e. we let the probe routines choose : what type of ISA bus to use). I think we should leave the hint-device : merging stuff until later as it requires to fix all the broken ISA : drivers to get it right. Actually, it doesn't require that we fix them. In an ideal world we'd only match on the HID (and not touch hardware) if a HID was provided, but the more I've thought about it, the more I think that probing for the device after matching the HID is OK. If the device doesn't match the HID, the probe will fail anyway without touching the hardware. Touching hardware when we fail the probe is where we run into trouble. It is OK to touch the hardware if the probe routine returns 0 because no other hardware can attach to it. The hints merging stuff could be done later, or by someone else. It would just be a modification of the isahint.c file, since I think that it gets done at the right time. The pnpisa driver is also a child of the ISA bus with an identify routine, so that wouldn't be a special case. We'd have to make sure that the pnp driver's identify routine was called before the isahint driver's identify routine. I think that we could do that after calling bus_generic_attach() and moving the isahint code into the isa (generic one) bus driver. But that relates back to your other question here about bus_generic_probe vs bus_generic_attach :-). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message