Date: Sat, 14 Oct 1995 19:19:43 +1000 From: Bruce Evans <bde@zeta.org.au> To: hackers@freebsd.org, msmith@atrad.adelaide.edu.au, uhclem%nemesis@fw.ast.com Subject: Re: I/O port 0 == autoconfig? - RESULTS Message-ID: <199510140919.TAA09173@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>3. "Don't have *ANY* drivers that figure out where the hardware is >(2 rsp) by searching for it using a clue list or any other mechanism. > Allow only a single-hardcoded location (resource) per driver > that is used if -1 is present, and if that isn't where the > hardware is, the user must change the setting using config." One is no better or worse than many, but none of the addresses should be ones that have already been probed and attached or otherwise reserved for other devices. Since there is currently no good way for drivers to tell which addresses are reserved, drivers shouldn't use hard-coded resource tables. Currently, drivers must advertise their resources in their isa_device struct _before_ they are probed. One hackish way around this would be to probe multiply. Drivers could then set up proposed resources for the next pass and be called for the next pass iff the resources don't conflict (something more would be required to change the resources for the next+1 pass). Unfortunately this would make the probe order hard to predict. It is already hard to predict because some drivers have an unadvertised `sensitive_hw' flag that affects the order, and the visual config changes the order to a "logical" one. Another way is to put multiple devices in the config: controller matcd at isa? port 0x230 bio controller matcd at isa? port 0x240 bio controller matcd at isa? port 0x250 bio controller matcd at isa? port 0x260 bio Hmm. isa_configure() can't check for conflicts properly because it doesn't know the number of ports before the probes. > If you follow the logic that the user won't know where -1 looks > for the driver that looks at locations X, Y and Z, he still > won't know what location is being accessed if the driver just looks > at location X. No difference here. The user will still have to > refer to documentation to find out where the driver is looking, > but he only looks if it doesn't work! That is the key. The driver should report what it's looking at if `bootverbose' is set. > If you go along with the user-should-be-fully-informed and > must-set-everything-exactly-right way of thinking (I guess this > is the same school that took the automatic IRQ mapping out of the > ed0 driver sometime back - grrr), then all drivers should list ed0 still does automatic irq mapping if that is specified (by `irq ?' in the config). Things broke because some config files specified wrong fixed irqs. The ed0 line in the GENERIC config is impossible to write correctly for all cases because ed0 handles dozens of cards and doesn't know the irq mappings for all of them. I don't know why it specifies fixed irqs though. > explicit settings in config, and not look anywhere else, nor should > they figure out anything for themselves. The Port/IRQ/DMA settings > should have no hidden meanings, such as changing a driver from > interrupt-driven to polled, etc. The Flags parameter should be used If the config specifies no irq, how is interrupt-driven i/o supposed to work? Drivers should figure out whatever they can do safely, i.e., very little given the available resources. >We must not forget the looming issue of Plug and Play devices, where >the entire point is for the drivers and initialization code to work >out where the hardware is, can and can't go, and to put it wherever >the pieces fit best. When that day comes, more and more drivers would >be "autoconfiguring", and our current method of reporting locations >back to the to-be-probed drivers and such will have to be replaced. >That is down the road a bit as the entire ISA probe/attach mechanism will >have to be re-written to handle it. This is certainly not a goal for >2.1, and I doubt anyone has thought about it much as an item for 2.2. >It will be nasty. ICU, anybody? isa_configure() is only supposed to work for configuration of isa devices :-). It will probably be sufficient for it to avoid stepping on already-configured autoconfigurable devices. The current init order is probably backwards - isa devices are probed first. Of course, the console should be probed first, and it may be isa for some time. >(2) On the religous front, "I'll do it to my code if you'll do it to >your code." :-) Well, I know that won't happen. However I'll bend, >and unless I hear a loud outcry, I'll change the config entry for matcd to >not search for its hardware BY DEFAULT and I'll pick one address. Zero addresses please. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510140919.TAA09173>