- Split if_fmv.c into MI/MD part and add ISA-PnP attachment for FMV-183.
(XXX FMV-184 is not tested. It would require extra media-select functions..)
- Fix probe functions of fmv_isa so that FMV-181A/182A will also match.
Fixes port-i386/9476.
using one word as both attribute and device doesn't work well,
radio.c is pulled in even with no such device in the configuration,
and the kernel doesn't link due to missing "radio_cd".
So call the attribute "radiodev" to avoid confusion.
not support a value (e.g., it's to be used as "options FOO" instead of
"options FOO=xxx"). options that take a value were converted to
defparam recently.
- minor whitespace & formatting cleanups
as config(8) will warn for value-less defparam options
- minor whitespace/formatting cleanup
- consolidate opt_tcp_recvspace.h and opt_tcp_sendspace.h into opt_tcp_space.h
remove all (legacy) "i4b_" prefixes outside of sys/netisdn.
Prefix all card specific driver support files with the basename
of the driver bus attachement file.
Renamed here:
i4b_isic_isa.c -> isic_isa.c
i4b_avm_a1.c -> isic_isa_avm_a1.c
i4b_daic_isa.c -> daic_isa.c
i4b_itk_ix1.c -> isic_isa_itk_ix1.c
i4b_tel_s08.c -> isic_isa_tel_s08.c
i4b_tel_s016.c -> isic_isa_tel_s016.c
i4b_tel_s0163.c -> isic_isa_tel_s0163.c
i4b_usr_sti.c -> isic_isa_usr_sti.c
This is the kernel part (userland to follow soon) of the latest (and
very probably last) release (version 0.96) of ISDN4BSD. ISDN4BSD has a
homepage at http://www.freebsd-support.de/i4b/.
It gives the user various ways to use the isdn connection: raw data (via
the i4brbch "raw b-channel" device), ppp (via the isp "isdn PPP" device),
voice/answering machine (the i4btel "telephone" device) and ip over isdn
(the ipr device, "IP over raw ISDN").
Supported are a bunch of common and older cards, more to be added soon
after some cleanup. Currently only the european E-DSS1 variant of the
ISDN D channel protocol is supported.
* Rearrange the speed mapping table and adjust the code so that the highest
rate can actually be used. Previously we ended up rounding up slightly
lower speeds and then losing because set_params couldn't set the mode
back to the current one.
* Allow 260 as a valid I/O address, since the SB1 can be jumpered to this.
* Change the MPU-401 code so it can be attached as a separate device.
(XXX Really, the SB code ought to just attach a subdevice itself.)
* Do not attach an OPL on the SB1. Writing to the OPL registers at
SB_base+0 on this card wedges my machine.
(XXX Should we access it at 388 instead? The Creative web site claims
that this board *does* have an OPL2, but I haven't played with this
extensively.)
* Allocate the SB DMA channels at open time, rather than attach time, so
that a single DRQ can be used for multiple cards (if only one is in use
at a given time).
(XXX Let me tell you why this is a horrible hack. If the ISA DMA code
tries to allocate a bounce buffer after boot time, it will generally fail,
because there is no contiguous memory below 16MB and the code to allocate
contiguous pages doesn't know how to move things around. Now, we
shouldn't ever be using bounce buffers here, because we use
isa_dmamem_alloc(). So we just turn off BUS_DMA_ALLOCNOW and we don't
actually try to. That's cool, and it even works, but isa_dmamem_alloc()
has the same problem. It just happens that we allocate the ring buffers
at boot time, and whenever we reallocate them (due to the buffer size
changing), we just deallocated the previous (contiguous) buffer, so we get
lucky. This is absolutely disgusting and needs to be fixed.)