How disable attachment of sio(4) driver to device?

[Frank Behrens]

Warner, John and others,

thanks for your fast responses.

John Baldwin <jhb at freebsd.org> wrote on 21 Oct 2005 12:16:
> But you could hack the sio(4) driver to check its IO port and return ENXIO if 
> it has a certain value, for example.

Yes, this would not be a problem for me. But I want to publish my 
driver as port and make it for the user as easy as possible. That 
includes not the need for building a new kernel.

M. Warner Losh <imp at bsdimp.com> wrote on 21 Oct 2005 10:06:
> Another "soltution" is to not have sio in your kernel while you are
> debugging your driver.

Well, you used already the quotes. It is not an option for me, 
because my system has no keyboard and monitor attached and the serial 
console is my only way to see the panic messages. ;-)

> Another solution would be to have your driver use the tty layer
> instead of banging the hardware directly, if that is compatible with
> the goals of your driver.  This solution isn't in quotes because for
> some class of devices (say a keyboard driver for a sun or apple newton
> keyboard that does serial), it might be the right one.

Hm, this looks even more complicated and has more overhead. To show 
shortly my requirements: The protocol is for an eib driver, (further 
information on http://www.sax.de/~frank/eib4bsd/), it uses 9600 baud 
on serial line. If the PC wants to send a telegram it resets RTS and 
has to poll CTS. If CTS is active the transmission of one byte is 
possible. If the last bit is sent (transceiver shift empty!) the PC 
sets RTS and waits until CTS is inactive. Then a new handshake can 
start and a transmission of about 30 bytes must be finished in 130 
ms. IMHO this can be handled only in an interrupt routine with low 
overhead.

M. Warner Losh <imp at bsdimp.com> wrote on 21 Oct 2005 11:37:
> I'd like to be able to say that sio0 is at handle=\_SB_.PCI0.PX40.UAR2
> rather than some arbitrary address.  Or that bge1 is at
> 
>             bge0 pnpinfo vendor=0x14e4 device=0x16a6 subvendor=0x14e4 subdevice=0x8009 class=0x020000 at slot=3 function=0 handle=\_SB_.PCI0.G0PA.LAN0
>               miibus0
>                 brgphy0 pnpinfo oui=0x818 model=0x16 rev=0x2 at phyno=1
>             bge1 pnpinfo vendor=0x14e4 device=0x16a6 subvendor=0x14e4 subdevice=0x8009 class=0x020000 at slot=4 function=0 handle=\_SB_.PCI0.G0PA.LAN1
> 
> either at pci2.4.0 *OR* at handle=\_SB_.PCI0.G0PA.LAN1 (or even
> handle=LAN1).  So there'd need to be some kind of bus specific mapping
> function that would say true or false if a given device_t on that bus
> matched the string presented.

For my driver I made already a sort of this. Part of my probe routine 
is
	if (resource_string_value(EIBNAME, 0, "at", &hintBus))
		return (ENXIO);
	if (strcmp(hintBus, "pci"))
		return (ENXIO);
	
	if (resource_int_value(EIBNAME, 0, "bus", &hint) == 0 &&
		pci_get_bus(device) != hint) {
		return (ENXIO);
	}
	if (resource_int_value(EIBNAME, 0, "slot", &hint) == 0 &&
		pci_get_slot(device) != hint) {
		return (ENXIO);
		}
	if (resource_int_value(EIBNAME, 0, "function", &hint) == 0 &&
		pci_get_function(device) != hint) {
		return (ENXIO);
	}



So my conclusion is:
1. Preventing a driver to attach to a specified resource is in 
current FreeBSD more complicated compared to FreeBSD 4.x

2. I will create a PR to change the sio(4) driver, that it returns 
BUS_PROBE_DEFAULT instead of BUS_PROBE_SPECIFIC.
Then further patching is not necessary.

Thanks for your suggestions. Regards,
   Frank
-- 
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.