Remove the clear-the-irq-after-enabling it dance (which had bad side
effects on some cards). Instead disble the ISAC receiver when we have
interrupts disabled. Adjust the interrupt handler to properly deal with
subtle differences of the ISAC implementation in IPAC chips.
into a strange failure mode if we do it with disabled interrupt. When
(re-)enabling interrupts reset transmitter and receiver and clear any
pending state.
for the same purpose (ignoring invalid interrupts).
For cards that are not able to stop all interrupts (or we don't know a way
to do that in software, at least) run the clearirq callback even when
ignoring an interrupt because we are not enabled. Otherwise the card would
stop interrupting.
Reserve a driver specific callout handle and an int value in the generic
isic_softc to allow card drivers to implement fancy blinkenlights.
and move them in their proper places.
Move the BRI registry from layer 2 (duh!) to layer 4, so active cards
(which don't have layer 3 or layer 2 in their driver). Remove all remaining
hard coded controller and driver types. Remove any arbitrary hard coded
limits, at least those that show up in the internal API.
This fixes PR 15950.
This now provides slightly more functionality than the FreeBSD layer1-newbus
interface. It was meant to be a simple change to one header and a few
c files, but the change rippled all through various stuff.
To prevent a change to the kernel<->userland interface right now the kernel
is now lying about card types to userland (but who cares). This will be fixed
when the userland interface changes, after layer 3 <-> layer 4 has been
fixed.
Functional changes:
Provide a clean interface for hardware drivers to attach to the upper
layers. This will need another small change in the B-channel handling
when a similar change to the layer 3 <-> layer 4 interface happens.
Avoid passing indices into global arrays of pointers around, instead pass
the pointers itself. Don't code hardware driver types by predefined magic
numbers (think LKM). Prepare for detachable drivers (think pcmcia).
While there remove some sets of function pointers always pointing to the
same function (meant to be the configurable set of D channel protocol
handlers). It is unlikely another supported D-channel protocol will fit into
that (maximal layer interface) abstraction. When we get support for another
protocol, we will need to come up with a workable interface. Besides, the
old implementation was, uhm, strange.
leo