Date: Wed, 20 Dec 2000 19:05:12 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: Mike Smith <msmith@freebsd.org> Cc: freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Request for comments: ISA_PNP_SCAN() (long) Message-ID: <200012201005.TAA04607@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "Wed, 20 Dec 2000 00:53:59 PST." <200012200853.eBK8rxQ15667@mass.osd.bsdi.com> References: <200012200853.eBK8rxQ15667@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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. Um, may be my wording was not appropriate. I didn't mean dynamic or active scanning of devices. Rather, I just wanted to have a routine to enlist PnP device instances hanging from the ISA bus, so that the hinted device will abondan its probe if there is a PnP sibling; no active scanning, probing, poking, or whatever, is involved and inteded. It should have been called ISA_PNP_PICK or ISA_PNP_FIND. >> 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. I thought so :-) >> 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: <PNP####> cannot assign resources". > >This is a known, longstanding bug in the current ISA bus implementation, I knew. >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.). How do we supposed to classify PnP devices into two groups? >With these probed >first, the hints are typically going to be ignored. So long as we have two device instances, a hinted instance and a PnP instance, for a single ISA device, the hinted instance will fail (rather than ingored), after the PnP instance succeeds (unless the hinted device instance is disabled or deleted). While the above scheme generally sounds good, we will still have a numbering problem, won't we? Hinted devices created by the isahint driver have the unit number 0 (because they are listed as such in /boot/device.hints), then the PnP instance for "foo" will have the unit number 1 when it attaches. The non-PnP (hinted) device instance for "foo" will fail (because resources are claimed by the PnP instance), and we will see "foo0: failed to probe" during boot if bootverbose is on. This is quite analogue to what I trid to fix by introducing ISA_PNP_SCAN/PICK/FIND(), which should be useful for the hinted/non-PnP instance to give way to its PnP counterpart. >> 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. Did you see my last code example in which non-PnP/hinted device instance will give way to the PnP instance? At least we are agreeing that there are two problems/bugs to be fixed :-) Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012201005.TAA04607>