Date: Sat, 24 Feb 1996 19:43:49 +0530 From: A JOSEPH KOSHY <koshy@india.hp.com> To: Terry Lambert <terry@lambert.org> Cc: freebsd-hackers@freebsd.org Subject: Re: ISA device irq/mem auto-configuration Message-ID: <199602241413.AA023091230@fakir.india.hp.com> In-Reply-To: Your message of "Thu, 22 Feb 1996 11:04:00 MST." <199602221804.LAA21281@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> tl == Terry Lambert said:
tl> If you could actually tell what it was configured for...
tl> Only "how do you know the board is at IRQ 11 when the probe code
tl> has to assume the interrupt for the probe to work?". 8-).
Not a problem on some boards: you can read h/w configuration registers
to figure out the IRQ that it has been configured to use. Now, this
can only be done if one is reasonably confident that the particular kind
of card is actually present so its best done /after/ a non-invasive
probe!
tl> I think this falls into the category of space assignment.
tl> It's probably not possible to safely relocate the board ...
Well, the question was if it was possible to update the kernel
internal data structures to suit the hardware configuration (not vice-versa).
The answers I got from the list seemed to indicate that it was ok to do so.
Following the probe, the kernel apparently does a conflict resolution pass
after all the drivers have been probed.
So this is what I plan to do:
(a) compile in wild-card defaults for IRQ, Mem address etc
(b) at probe time if these are wildcarded use the hardware info, else print
out an informative message about the mismatch but leave the driver disabled.
This allows the user to explicitly specify driver settings using boot -c
and have the boot process honor them.
Koshy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602241413.AA023091230>