Date: Fri, 12 Sep 1997 06:30:16 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: mike@smith.net.au (Mike Smith) Cc: mike@smith.net.au, gurney_j@resnet.uoregon.edu, perhaps@yes.no, freebsd-hackers@FreeBSD.ORG Subject: Re: PnP support Message-ID: <199709120430.GAA02186@labinfo.iet.unipi.it> In-Reply-To: <199709120335.NAA01011@word.smith.net.au> from "Mike Smith" at Sep 12, 97 01:35:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Yes. > > > > PnP probe > > > get ISA config (compiled in, datafile, etc.) > > > > this means probe the isa devices and trust what the config info > > say. At this point we have already effectively allocated 'extents' > > for legacy ISA devices. > > No, this means read the compiled in hints for brute-force ISA probes. not sure. take the case of GENERIC, where all sort of hardware is compiled in, possibly at conflicting addresses, and no actual conflicts are present since not all devices are really present. How do you tell without probing ? > In the gather phase, we do *nothing* with the hardware that might cause > any sort of confusion. ... > > Also, while we are on the subject: some legacy ISA device also have > > software-configurable resources such as DMA or IRQ channels. methods > > are device-specific (pre-PnP). > > In the case of the 3c509, for example, you have a "pseudo-PnP" probe > for it which would run just after the "real" PnP probe. As long as the > "smart" probe can provide the basic information required to configure > the hardware and select a driver, it qualifies as PnP. ok, fine. Luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709120430.GAA02186>