From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 17:17:30 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F10316A41C; Mon, 18 Jul 2005 17:17:30 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A9A543D45; Mon, 18 Jul 2005 17:17:27 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6IHHOo5030765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Jul 2005 10:17:25 -0700 Message-ID: <42DBE22D.8020308@root.org> Date: Mon, 18 Jul 2005 10:09:01 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20050716.113059.82101301.imp@bsdimp.com> <20050716.131701.124866666.imp@bsdimp.com> <42D9DA05.1020806@root.org> <200507180715.41974.jhb@FreeBSD.org> In-Reply-To: <200507180715.41974.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, harrycoin@qconline.com, "M. Warner Losh" Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 17:17:30 -0000 John Baldwin wrote: > On Sunday 17 July 2005 12:09 am, Nate Lawson wrote: >>Rather than John's addition of returning an arbitrary CID, can we return >>~0 or some other obviously invalid HID so that drivers don't start >>depending on the order of CIDs? > > > Actually, drivers also use isa_get_logicalid() to get real actual PnP ID as > well (see usage in the pnpmss driver in the same file). I think that any > drivers that actually need to interface with ACPI do need to just use > ISA_PNP_PROBE(). Yes, there is no way for a driver to work correctly using just isa_get_logicalid() on all systems. The problem with this is that CID is a list of IDs, some private that will never match a driver like mss. For example, using bogus IDs: System1 _HID: none _CID: IBM008, PNP0C02, PNP0C01 If you just return the first CID in isa_get_logicalid() like your patch does, the device won't probe correctly since IBM008 is not matched by mss. However, on System2: System2 _HID: none _CID: PNP0C02, IBM008, PNP0C01 It works! Thus if a developer of mss only used System2 with your patch, there would be no problem until someone tried on System1. Using ISA_PNP_PROBE() solves this, like you say. To prevent this, should we even issue a warning if acpi_isa_get_logicalid() did not find a _HID but a _CID exists? > I think that drivers that don't implement devices ACPI > enumerates should stop attaching to ACPI as well. Finally, it may be that > ISA_PNP_PROBE() needs to return a string version of the PNP ID that was > actually probed so that drivers can do extra tests. First though, we should > go through removing extra acpi attachments for drivers for ISA PNP cards > since ACPI enumerates the equivalent of PNP BIOS, not ISA PNP. This sounds good. -- Nate