sfc: Remove confusing MMIO functions
authorBen Hutchings <bhutchings@solarflare.com>
Tue, 18 Sep 2012 00:56:50 +0000 (01:56 +0100)
committerBen Hutchings <bhutchings@solarflare.com>
Sat, 1 Dec 2012 00:26:11 +0000 (00:26 +0000)
commit778cdaf639e34288c298f1d3d3503d0724ceabc7
tree1a88ba2e73096166ce7c3021ddd70effe34f8d1d
parentbbec969b7f57a6ab5683145b99da869f99080e2a
sfc: Remove confusing MMIO functions

efx_writed_table() uses a step of 16 bytes but efx_readd_table() uses
a step of 4 bytes.  Why are they different?

Firstly, register access is asymmetric:

- The EVQ_RPTR table and RX_INDIRECTION_TBL can (or must?) be written
  as dwords even though they have a step size of 16 bytes, unlike
  most other CSRs.
- In general, a read of any width is valid for registers, so long as
  it does not cross register boundaries.  There is also no latching
  behaviour in the BIU, contrary to rumour.

We write to the EVQ_RPTR table with efx_writed_table() but never read
it back as it's write-only.  We write to the RX_INDIRECTION_TBL with
efx_writed_table(), but only read it back for the register dump, where
we use efx_reado_table() as for any other table with step size of 16.

We read MC_TREG_SMEM with efx_readd_table() for the register dump, but
normally read and write it with efx_readd() and efx_writed() using
offsets calculated in bytes.

Since these functions are trivial and have few callers, it's clearer
to open-code them at the call sites.  While we're at it, update the
comments on the BIU behaviour again.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
drivers/net/ethernet/sfc/io.h
drivers/net/ethernet/sfc/nic.c
drivers/net/ethernet/sfc/siena_sriov.c