Overhaul bus_dma(9) usage in et(4) and clean up TX/RX path. This

change should make et(4) work on any architectures.
 o Remove m_getl inline function and replace it with stanard mbuf
   interfaces.  Previous code tried to minimize code duplication
   but this came from incorrect use of common DMA tag.
   Driver may be still use a common RX allocation handler with
   additional structure changes but I don't see much point to do
   that it would make it hard to understand the code.
 o Remove DragonflyBSD specific constant EVL_ENCAPLEN, use
   ETHER_VLAN_ENCAP_LEN instead.
 o Add bunch of new RX status definition.  It seems controller
   supports RX checksum offloading but I was not able to make the
   feature work yet.  Currently driver checks whether recevied
   frame is good one or not.
 o Avoid a typedef ending in '_t' as style(9) says.
 o Controller has no restriction on DMA address space, so there
   is no reason to limit the DMA address to 32bit.  Descriptor
   rings,  status blocks and TX/RX buffers now use full 64bit DMA
   addressing.
 o Allocate DMA memory shared between host and controller as
   coherent.
 o Create 3 separate DMA tags to be used as TX, mini RX ring and
   stanard RX ring.  Previously it created a single DMA tag and it
   was used to all three rings.
 o et(4) does not support jumbo frame at this moment and I still
   don't quite understand how jumbo frame works on this controller
   so use two RX rings to handle small sized frame and normal sized
   frame respectively.  The mini RX ring will be used to receive
   frames that are less than or equal to 127 bytes.  The second RX
   ring is used to receive frames that are not handled by the first
   RX ring.
   If jumbo frame support is implemented, driver may have to choose
   better RX scheme by letting the second RX ring handle jumbo
   frames.  This scheme will mimic Broadcom's efficient jumbo frame
   handling feature.  However RAM buffer size(16KB) of the
   controller is too small to hold 2 jumbo frames, if 9KB
   jumbo frame is used, I'm not sure how good performance would it
   have.
 o In et_rxeof(), make sure to check whether controller received
   good frame or not.  Passing corrupted frame to upper layer is
   bad idea.
 o If driver receives a bad frame or driver fails to allocate RX
   buffer due to resource shortage condition, reuse previously
   loaded DMA map for RX buffer instead of unloading/loading RX
   buffer again.
 o et_init_tx_ring() never fails so change return type to void.
 o In watchdog handler, show TX DMA write back status of errored
   frame which could be used as a clue to debug watchdog timeout.
 o Add missing bus_dmamap_sync() in various places such that et(4)
   should work with bounce buffers(e.g. PAE).
 o TX side bus_dmamap_load_mbuf_sg(9) support.
 o RX side bus_dmamap_load_mbuf_sg(9) support.
 o Controller has no DMA alignment limit in RX buffer so use
   m_adj(9) in RX buffer allocation to make IP header align on 2
   bytes boundary.  Otherwise it would trigger unaligned access
   error in upper layer on strict alignment architectures.
   One of down side of controller is it provides limited set of RX
   buffer length like most Intel controllers.  This is not problem
   at this moment because driver does not support jumbo frame yet
   but it may require alignment fixup code to support jumbo frame
   on strict alignment architectures.
 o In et_txeof(), don't zero TX descriptors for transmitted frames.
   TX descriptors don't need write access after transmission.
   Driver sets IFF_DRV_OACTIVE when the number of available TX
   descriptors are less than or equal to ET_NSEG_SPARE.  Make sure
   to clear IFF_DRV_OACTIVE only when the number of available TX
   descriptor is greater than ET_NSEG_SPARE.

0 files changed, 0 insertions, 0 deletions