From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 10 14:54:10 2006 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4767816A55C; Mon, 10 Jul 2006 14:54:10 +0000 (UTC) (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 BD1C943D49; Mon, 10 Jul 2006 14:54:09 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6AEpNo0019984; Mon, 10 Jul 2006 08:51:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 10 Jul 2006 08:51:33 -0600 (MDT) Message-Id: <20060710.085133.-432771632.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200607101034.38923.jhb@freebsd.org> References: <20060709.022224.-1827343921.imp@bsdimp.com> <200607101034.38923.jhb@freebsd.org> X-Mailer: Mew version 4.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: acpi@freebsd.org Subject: Re: PERFORCE change 101080 for review X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 14:54:10 -0000 In message: <200607101034.38923.jhb@freebsd.org> John Baldwin writes: : On Sunday 09 July 2006 04:22, M. Warner Losh wrote: : > : > John, : > : > I think the following change is good reguardless of how the current : > discussions about how to get acpi devices wired falls out. It : > modifies devclass unit number assignment to treat a pre-existing : > device as 'taken' as well as one that just might be hinted at. : > : > It has the nice side effect of obviating the need for device_set_unit, : > which I added holding my nose a long time ago. The reason I didn't go : > with this approach was that at the time (4.x or maybe 3.x) there : > wasn't the hints infrastructure we have today, and I never went back : > to revisit this kludge to remove it. : > : > Please let me know what you think of this. : : Well, I think perhaps you think my wiring stuff is just about serial : ports, No. I absolutely do not. : but it really would allow us to generically wire unit numbers : based on properties of the device that the bus driver can verify : (resources, location, etc.) It does allow us to do that, but I don't see the point for PCI devices. : Basically, I want the bus driver to decide : if it wants to "claim" a hint device. That is, each time we go to probe : a device, if there are any hint-enumerated devices for the child driver : we are probing, we pass the device_t to the parent (bus) device_t and use : a new bus_if.m method to ask the parent bus if it's ok for this device_t : to "take over" the hint device (e.g. if the resources specified in the : hint are a subset of the ACPI or PNPBIOS-enumerated resources). Since : each bus is free to implement whatever algorithm it wants, we can also : add creative things like: : : hint.foo.0.at="pci:0:4:0" (a PCI bus/device/function) : : or : : hint.foo.0.at="_SB_.PCI0.ISA0.FOO0" (an ACPI device name) : : because the bus (and not the MI subr_bus.c code) is determines what the : hints mean. Can't use 'at' for this purpose. 'at' isn't a location, but a bus specifier. You'll need to invent something else. I get that, so don't go assuming that I don't. You didn't answer my question: is the patch I posted good or not. I think it is absolutely necessary, reguardless of the outcome of this discussion. Like I said, I've been doing a lot of thinking about how to accomplish this. Your proposal is way too complicated. After thinking about it all weekend, I'm sure that we can do all the wiring (to both a location in a namespace, as well as to a resource "location") using the patch I posted, plus the hints stuff I created for the iic/spi bus stuff. Upon reflection, it turns out to be a lot more general. Warner