if_xname, if_dname, and if_dunit. if_xname is the name of the interface
and if_dname/unit are the driver name and instance.
This change paves the way for interface renaming and enhanced pseudo
device creation and configuration symantics.
Approved By: re (in principle)
Reviewed By: njl, imp
Tested On: i386, amd64, sparc64
Obtained From: NetBSD (if_xname)
connections that have been open (and were not closing) when
the interface was stopped. This makes the behaviour of fatm(4) more like
the behaviour of en(4).
careful to call all map_load calls with BUS_DMA_NOWAIT because we
really don't want some PDUs to wait while others go out - ATM guarantees
the ordering of cells and also of PDUs (within one VC, that is). With
BUS_DMA_NOWAIT bus_dmamap_load should never return EINPROGRESS.
Make the tag used for transmission buffers one larger than the maximum
AAL5 PDU (65535). This is needed, because all PDU sizes need to be round
up to multiple of four for the card and PDUs that are just below the
maximum size will be rounded up to 65536
Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.
Reviewed by: tmm, gibbs
