From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 06:52:28 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 5927816A41C for ; Sun, 17 Jul 2005 06:52:28 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9862143D46 for ; Sun, 17 Jul 2005 06:52:27 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6H6nIie025333; Sun, 17 Jul 2005 00:49:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 17 Jul 2005 00:50:01 -0600 (MDT) Message-Id: <20050717.005001.38197608.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <42D9DA05.1020806@root.org> References: <20050716.125824.48530425.imp@bsdimp.com> <20050716.131701.124866666.imp@bsdimp.com> <42D9DA05.1020806@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, harrycoin@qconline.com 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: Sun, 17 Jul 2005 06:52:28 -0000 In message: <42D9DA05.1020806@root.org> Nate Lawson writes: : M. Warner Losh wrote: : > : > Nate writes: : > : >>I really think the driver is broken and the API is fine for this. I : >>don't like the hack of returning a random CID for checks against the : >>HID. Drivers down the road may come to rely on this and then every BIOS : >>that has a different order for CIDs becomes a potential breakage point. : > : > : > They alredy do rely on this. When they support pnp, they call the : > ISA_PNP_PROBE routine. When they don't then your observation doesn't : > matter because the order of the IDs doesn't matter: their non-zeroness : > does. : > : > : >>Drivers should not rely on isa_get_logicalid() to determine a boolean : >>"is PNP?" : > : > : > Actually, that's the interface. We have to follow it, even if you : > think it is stupid. It is how we do things. When we don't have a : > logicalid, we return 0. When drivers don't support pnp devices, it : > uses the existance of a non-zero pnpid to know the device isn't for : > them. It has been this way since 3.0. : > : > Warner : : 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? That might not be a bad idea. I'm not sure the right thing to do is. I know this would break at least one sound driver, but I believe that sound driver is broken anyway. Warner