From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:11:59 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 9E41A16A41C; Sat, 16 Jul 2005 17:11:59 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2461143D49; Sat, 16 Jul 2005 17:11:59 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Sat, 16 Jul 2005 12:12:43 -0500 Message-Id: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 16 Jul 2005 12:11:50 -0500 To: "M. Warner Losh" ,nate@root.org From: Harry Coin In-Reply-To: <20050716.103028.04060625.imp@bsdimp.com> References: <42D82D59.9060605@root.org> <200507121027.14113.jhb@FreeBSD.org> <4.3.2.7.2.20050715164008.01f0fdd8@mail.qconline.com> <42D82D59.9060605@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org 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: Sat, 16 Jul 2005 17:11:59 -0000 At 10:30 AM 7/16/2005 -0600, M. Warner Losh wrote: >Nate's right here. It isn't needed. The ISA_PNP_PROBE is for all >devices that have a PNP ID. Thse includes ISA PnP cards, PNP BIOS >devices and ACPI devices. So the device_is_pnp() isn't needed at all. > >Warner I think all that's needed to wrap this up is for the powers that be to offer clarity about one thing, final decision about the case of arbitrary (beyond com1, etc.) non-pnp ISA devices probe routines. A great many sound chips of various register demands are in this list. (Admittedly older devices, but I ran into serious breakage of an isa pnp device driver because of interactions with the related non-pnp probe routine that supported earlier chipsets in the same family that were largely register compatible with the pnp versions). Seems either 1) Document a way or make an OS change to make certain non-pnp isa probe routines are never called any time while pnp isa resources haven't been put to sleep. So that these probe routines will only be called after the field is clear and they can rummage around the register space looking for their chips -- and they don't accidentally find compatible PCI versions previously or yet to be found by their PCI probe modern driver cousins. The isa part of the architecture manual ought to be updated to reflect how properly to do this. (Are there cases where the non-pnp routines being called in the acpi context pass the currently iffy pnp-gate and find and enable operations of pnp chips that the pnp-routines don't have in their 'acceptable id' list? My hunch in the sound chip world is 'yes'. So this fix might break audio on systems that don't have the pnp ids in the pnp soundchip ISA_PROBE roster as yet.) or 2) change non-pnp isa drivers to do as the architecture manual currently suggests, with inelegance that John noted (ISA_PNP_PROBE with the null list then continue only if no pnp id for the device). or 3) make a device_is_pnp OS call that does 2 and avoids the inelegance, then update the architecture manual for isa drivers and also the isa drivers themselves. or 4) I can't think of a 4, but I'm sure there is a 4. There's always a 4. Please pick and announce! Harry