Date: Thu, 11 Sep 1997 22:45:48 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gurney_j@resnet.uoregon.edu Cc: tlambert@primenet.com, luigi@labinfo.iet.unipi.it, mike@smith.net.au, perhaps@yes.no, freebsd-hackers@FreeBSD.ORG Subject: Re: PnP support Message-ID: <199709112245.PAA17225@usr03.primenet.com> In-Reply-To: <19970911142544.37798@hydrogen.nike.efn.org> from "John-Mark Gurney" at Sep 11, 97 02:25:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Only if the failing device can be disabused of the resources it's > > known to use. This will only work for PnP devices, where the card > > may be disabled, and then only in the case that the OS provides PnP > > BIOS type services to do the port diddling necessary to shut the > > device down. Otherwise, the failing device must be assumed to be > > activated. > > hmm.. very good point... so we need to make sure that upon a failed > attach that the device will leave the structure with a correct list > of resources that are active... i.e. most likely just the iobase and > memory mapped space... but it coulde leave irqs active... if they > do, we should probably make a small routine that will catch these > "stray" irqs and not through them in with the generic stray ones.. I was actually thinking about a "dummy" driver that pretended to be a device driver for the devices. This would actually allow a boot -c (if it could edit the irq/io/base) to be used to configure dummy devices into the conflict space so that nothing gets located on top of them. > > Note that a PnP BIOS for a particular board may have ISA devices > > defined as if they were PnP devices, in order to consider them in > > the PnP conflict resolution phase. Though these devices appear to > > be PnP devices, and therefore you might believe that you could > > disable them if you didn't have a suitable driver, and reclaim > > their resources, you CANNOT. They will not obey the disable > > requests. Thus PnP BIOS alone is not enough; an OS must provide > > its own PnP BIOS type services to be able to distinguish these > > devices. > > umm.. you lost me there.. you mean that some motherboards ACTUALLY > present the hardware emulation of the PnP card for legacy isa hardware? > I really have a feeling that you didn't mean this... My PnP machine here lets me define 2 ISA devices in CMOS setup, in addition to the ISA devices on the motherboard. It presents these devices as pseduo PnP devices with hard-coded values which can't be reconfigured via the BIOS because the controller for the device (generally a multi-i/o chip on the motherboard for motherboard stuff, or a legacy ISA card for the two I can configure) won't repond to PnP port munging of card resources because it *can't*. So if your "mung" was "disable this device so I can reclaim its address space", it won't work. Likewise, if your "mung" was "bsearch for PnP devices", it wouldn't find the ones from your PnP BIOS ROMs for the machine, or in the two CMOS areas that the PnP BIOS ROMs for your machine kenw about. That's why it's important to have a PnP aware OS that can do port munging, even if the machine has a PnP BIOS, and why it's important to use the PnP BIOS, if it's there, for "ISA device" identification for motherboard and CMOS setup "ISA devices". Note 1: It is vendor dependent whether the faked up PnP devices will show that the only setting they have, or whether it will claim all possible settings as configurations. As a rule of thumb, if you can change the device settings in the CMOS (COM1: IRQ, etc.), then it generally will report all possible settings. Note 2: If your machine has a PnP BIOS, the devices are configured after PnP POSTs. The only issue you have are legacy ISA devices that the BIOS doesn't know about, either because it's a minimal BIOS, or because you haven't told it. The ACER bus mouse example, where PnP stomps IRQ 12, is an example of a minimal BIOS. > > I *highly* recommend that anyone coding on this obtain a recent > > copy of the PnP specification, and consider these issues in their > > design. > > hmm... I probably should, could you mail me the reference in private > email? Plug and Play System Architecture, First Edition MindShare, Inc. ISBN: 0-201-41013-3 It's actually better than the spec., IMO. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709112245.PAA17225>