The pidx argument of isc_rxd_flush() indicates which is the last valid
receive descriptor to be used by the NIC. However, current code has
multiple issues:
- Intel drivers write pidx to their RDT register, which means that
NICs will only use the descriptors up to pidx-1 (modulo ring size N),
and won't actually use the one pointed by pidx. This does not break
reception, but it is anyway confusing and suboptimal (the NIC will
actually see only N-2 descriptors as available, rather than N-1).
Other drivers (if_vmx, if_bnxt, if_mgb) adhere to this semantic).
- The semantic used by Intel (RDT is one descriptor past the last
valid one) is used by most (if not all) NICs, and it is also used
on the TX side (also in iflib). Since iflib is not currently
using this semantic for RX, it must decrement fl->ifl_pidx
(modulo N) before calling isc_rxd_flush(), and then the
per-driver callback implementation must increment the index
again (to match the real semantic). This is confusing and suboptimal.
- The iflib refill function is also called at initialization.
However, in case the ring size is smaller than 128 (e.g. if_mgb),
the refill function will actually prepare all the receive
descriptors (N), without leaving one unused, as most of NICs assume
(e.g. to avoid RDT to overrun RDH). I can speculate that the code
looks like this right now because this issue showed up during
testing (e.g. with if_mgb), and it was easy to workaround by
decrementing pidx before isc_rxd_flush().
The goal of this change is to simplify the code (removing a bunch
of instructions from the RX fast path), and to make the semantic of
isc_rxd_flush() consistent across drivers. To achieve this, we:
- change the semantics of the pidx argument to the usual one (that
is the index one past the last valid one), so that both iflib and
drivers avoid the decrement/increment dance.
- fix the initialization code to prepare at most N-1 descriptors.
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D26191
Previously we were relying on ether_ifattach() to set if_mtu, but
max_frame_size is initialized earlier. This fixes a regression
introduced by r250375.
PR: 249050
Submitted by: Christian Vallières <novacrash_@hotmail.com>
MFC after: 3 days
Implement support for an eSDHC controller found in NXP QorIQ Layerscape SoCs.
This driver has been tested with NXP LS1046A and LX2160A (Honeycomb board),
which is incompatible with the existing sdhci_fsl driver (aiming at older
chips from this family). As such, it is not intended as replacement for
the old driver, but rather serves as an improved alternative for SoCs that
support it.
It comes with support for both PIO and Single DMA modes and samples the
clock from the extres clk API.
Submitted by: Artur Rojek <ar@semihalf.com>
Reviewed by: manu, mmel, kibab
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential Revision: https://reviews.freebsd.org/D26153
Previously the send tag was setup in the background, and all packets for
the given send tag were dropped until ready. Change this to be blocking
behaviour so that once the setsocketopt() for enabling TLS completes,
the socket is ready to send packets. Do this by simply flushing the
work request which does the needed firmware programming during send
tag allocation.
MFC after: 1 week
Sponsored by: Mellanox Technologies // Nvidia
The "Intel Sunrise Point-LP USB 3.0 controller" doesn't update the wMaxPacket
field in the control endpoint context automatically causing a BABBLE error code
on the initial first USB device descriptor read, when the bMaxPacketSize is not
8 bytes.
Reported by: wulf@
PR: 248784
MFC after: 1 week
Sponsored by: Mellanox Technologies
These devices have non-pccard attachments. Warn for those as well. Both an and
wi don't do the modern cyrpto needed to use these cards on secure wifi networks.
an needs firmware from Cisco, which I don't think was ever produced. wi could
in theory do it with raw frames and on-host encryption, but nobody has written
that in the 15 years since WEP was cracked.
MFC After: 3 days
Noticed by: rgrimes
Differential Revision: https://reviews.freebsd.org/D26138
