From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 30 21:13:37 2006 Return-Path: X-Original-To: freebsd-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 DA67716A50A for ; Mon, 30 Oct 2006 21:13:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64FF843D49 for ; Mon, 30 Oct 2006 21:13:36 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k9ULDEUc082234; Mon, 30 Oct 2006 16:13:33 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nate Lawson Date: Mon, 30 Oct 2006 15:21:01 -0500 User-Agent: KMail/1.9.1 References: <200610261423.04670.jhb@freebsd.org> <4541254E.5020108@root.org> In-Reply-To: <4541254E.5020108@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610301521.01983.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 30 Oct 2006 16:13:34 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2132/Mon Oct 30 14:42:34 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: smbios.ko probes successfully if i disable acpi sysresource, fails if i do not 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, 30 Oct 2006 21:13:37 -0000 On Thursday 26 October 2006 17:14, Nate Lawson wrote: > John Baldwin wrote: > > On Thursday 26 October 2006 12:28, Nate Lawson wrote: > >> John Utz wrote: > >>> Hello; > >>> > >>> as you may know i am attempting to use fbsd's smbios functionality to > >>> support porting the linux i8k-utils dell smbios keyboard and fan stuff. > >>> > >>> i just discovered today that disabling sysresource allows the module to > >>> attach. > >>> > >>> so, here's the part that i'd love some help with understanding: > >>> > >>> 1. with acpi enabled, is smbios.ko supposed to be asking acpi for a > >>> resource handle or something? > >>> > >>> 2. is acpi_resource.c behaving in error? should it not be consuming the > >>> smbios startaddr? > >>> > >>> note that startaddr for smbios is 0xf000, bios.c looks for pnpbios and > >>> pcibios starting at 0xe000 and completely ignores smbios. > >>> > >>> it seems to me that either statement 1 or 2 is correct, but not both. > >>> > >>> of course, i could be totally wrong, can anybody enlighten me? > >> ACPI reserves sysresource objects for downstream devices. Then, those > >> devices get the resources they request via ACPI. Anyway, all this > >> should be transparent to the downstream devices. They shouldn't care if > >> they're getting their resources from nexus (top, pseudo-device) or acpi. > >> > >> Are you using bus_alloc_resource() or the equivalent to get the > >> resources in your driver? It transparently maps resource requests to > >> upstream devices. Please send the output of devinfo -rv with your > >> driver installed, both with and without sysresource enabled in ACPI. > > > > smbios is attached to nexus though, so acpi isn't upstream. > > > > Why is smbios on nexus? It seems desirable to have it under the > top-level bus, which would be acpi if it is not disabled. Also, npx > should be there too (additional rationale: npx devices are defined in > the acpi Device namespace). Because they aren't ACPI specific, and if we go that route we'll have to make several drivers attach to both acpi and legacy. This would work if acpi and legacy were named differently (platform0 maybe, and you have two 'platform' drivers, nexus adds a platform device, and legacy and acpi both get to probe it, but acpi returns higher probe value on success). -- John Baldwin