This chip has a bit (misnamed TCR_FDUPLX) which is supposed to
specifically enable receiving of packets that it sent.  We disable
this.  Unfortunately, it sounds like this bit is ignored in
promiscuous mode.  What this effectively means is that normally the
chip is in `simplex' mode (IFF_SIMPLEX), but when promiscous mode
(RCR_PROMISC) is enabled, the device is no longer `simplex' and thus
violates some assumptions.


As is true of all non-`simplex' devices, we need to drop one side of
the tap.  Unfortunately there are disadvantages either way:

* If we drop it on the output side, we could lose the tap if the
  receive buffers are all full.

* If we drop it on the input side, someone could send us packets from
  our own MAC address, probably attempting to exercise security holes,
  and we wouldn't be able to trace them.

The lesser of the two evils is probably to drop it on the output side.
But note that this applies to all packets, not just unicast.


Also, since we're setting IFF_SIMPLEX, we should not receive this
packet again, since the network stack already looped it back
internally if necessary.  Doing so causes a duplicate packet to reach
the upper-level protocols, which is canonically wrong.  It is already
the case that smc91cxx_read() drops multicast and broadcast packets
from our address in promiscuous mode; it needs to be adjusted to also
do so for unicast packets (i.e. by just removing the test on the
destination address).  In addition, this block should be moved *after*
the call to bpf_mtap().


Similar logic in other drivers should also be adjusted if necessary.