From owner-freebsd-hackers Wed Dec 20 0:43:48 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 20 00:43:45 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-107.dsl.snfc21.pacbell.net [63.202.177.107]) by hub.freebsd.org (Postfix) with ESMTP id 1F5FC37B400 for ; Wed, 20 Dec 2000 00:43:45 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id eBK8rxQ15667; Wed, 20 Dec 2000 00:53:59 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200012200853.eBK8rxQ15667@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Kazutaka YOKOTA Cc: freebsd-hackers@freebsd.org Subject: Re: Request for comments: ISA_PNP_SCAN() (long) In-reply-to: Your message of "Wed, 20 Dec 2000 14:55:01 +0900." <200012200555.OAA01093@zodiac.mech.utsunomiya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Dec 2000 00:53:59 -0800 From: Mike Smith Sender: msmith@mass.osd.bsdi.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is to propose a new ISA bus method to sys/isa/isa_common.c. > The new method is to enumerate PnP device instances matching the > specified PnP IDs. (Well, may be this is a kludge after all.) > > device_t ISA_PNP_SCAN(device_t bus, struct isa_pnp_id *ids, int *n); > > It will return the (n + 1)th instance of the given PnP IDs on the > specified ISA bus. You set -1 to n to obtain the first PnP instance > matching the given PnP IDs and can enumerate all matching instances > by calling ISA_PNP_SCAN() until it returns NULL. This sort of active scanning for devices does not interact well with the way that our current bus architecture works. In particular, it makes it very difficult to implement the "bidding" process that allows us to have several drivers which might support the same device. > The trouble is that we always need to have hints for this driver in > /boot/device.hints for those systems without a PnP BIOS. Then, the > isahint driver will create a device instance. The pnpbios driver will > create a PnP device instance separately if the PnP BIOS exists and > reports the presence of a device. Yes. This is intentional. > Problem 1: > In -CURRENT the non-PnP device instance is probed first. If this is > successful, it will become available to the system as the 'foo0' > device. Probe on the PnP device instance will fail in this case > because the resources for this device has already been claimed by the > non-PnP device instance, and the user will see erroneous boot message > "unknown: cannot assign resources". This is a known, longstanding bug in the current ISA bus implementation, and it needs to be fixed. The correct ordering requires sorting the PnP devices into two classes; those which can be configured/disabled, and those which cannot. - Enumerate all PnP devices. - Disable PnP devices which can be disabled. - Probe/attach PnP devices which cannot be disabled. - Probe/attach ISA-hinted devices. - Probe/attach remaining PnP devices. This actually works better than expected because the PnP devices that most people are upset about conflicting with the hints are devices which can't be disabled (eg. onboard serial ports, etc.). With these probed first, the hints are typically going to be ignored. > Problem 2: > If the non-PnP device instance fails probe (because device hints are > wrong), the PnP device instance will succeed (because its resource > description is supposed to be correct). The PnP device instance will > become available in the system as 'foo1', rather than 'foo0'. This is > because the non-PnP device instance wasn't deleted after its probe > failed. This is also a bug, and fixing it would be desirable. If a probe based on hints fails, the hints are clearly invalid. > To avoid the second problem, we may prepare two separate drivers for > non-PnP and PnP device instances as follows. This is not (IMO) the correct solution. The bugs above should be fixed instead. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message