Date: Wed, 22 Aug 2007 22:25:16 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: cnst@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: device hints for isa modules Message-ID: <20070822.222516.-1749707994.imp@bsdimp.com> In-Reply-To: <46CB625D.7040505@FreeBSD.org> References: <46CB625D.7040505@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <46CB625D.7040505@FreeBSD.org>
"Constantine A. Murenin" <cnst@freebsd.org> writes:
: Dear freebsd-hackers@,
:
: Is there a way to statically compile device hints into an isa(4) module?
:
: From what it looks, there is no place in the source tree to put the
: hints for isa(4) modules -- you either have to place default hints into
: GENERIC.hints, implying that the driver will be compiled into a GENERIC
: kernel, or place it into NOTES. In the former case, having a module is
: then useless; in the latter, the module simply ain't going to work.
No. It isn't useless. If you have a driver listed in GENERIC.hints,
but not GENERIC, then there's no driver that will be attached and the
hint will effectively be ignored. If you later load a driver of the
proper name, it will use the hints. We do this all the time at work
so that we can load our drivers and have them probe/attach for the
custom ISA hardware we produce (it doesn't do ISA PNP).
You actually need to place them in both places.
: This is complicated further by the fact that changing isa hints after
: the boot has no effect on isa driver modules that use standard methods
: of resource acquisition. (Specifically, notice that kenv(1) won't give
: you an error message when you try to create a new hint or update an
: existing one, and the new or updated hint will in fact be visible back
: from kenv(1), but it won't have any effect on bus_alloc_resource(9)
: calls, thus modules depending on isa hints will fail to find their
: hardware.)
This is actually a bug. It would be desirable to place hints into the
hint space after boot.
: I'm specifically looking for a solution to a usable module for my lm(4)
: driver in soc2007/cnst-sensors perforce branch...
Just add them to GENERIC.hints. Then if/when your driver is loaded,
it will properly probe/attach. If it is never loaded, then there's no
real harm.
I have a kernel without sio. Yet I have the following hints:
hint.sio.0.at="isa"
hint.sio.0.flags="0x10"
hint.sio.0.irq="4"
hint.sio.0.port="0x3F8"
hint.sio.1.at="isa"
hint.sio.1.irq="3"
hint.sio.1.port="0x2F8"
hint.sio.2.at="isa"
hint.sio.2.disabled="1"
hint.sio.2.irq="5"
hint.sio.2.port="0x3E8"
hint.sio.3.at="isa"
hint.sio.3.disabled="1"
hint.sio.3.irq="9"
hint.sio.3.port="0x2E8"
The only side effect you'll see is with devinfo -v:
nexus0
acpi0
pcib0 pnpinfo _HID=PNP0A03 _UID=1 at handle=\_SB_.PCI0
pci0
isab0 pnpinfo vendor=0x1002 device=0x4377 subvendor=0x0000 subdevice=0x0000 class=0x060100 at slot=20 function=3 handle=\_SB_.PCI0.LPC0
isa0
sio0
sio1
sio2
sio3
devinfo doesn't show it. kldstat on my box doesn't list any sio
devices. When I load sio.ko, sio0-sio3 do not attach because I don't
have any real COMx devices.
This is a little confusing, but has proven to be fairly useful in
practice. It would be a little nicer if devinfo -v reported if the
device was attached or not...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070822.222516.-1749707994.imp>