@@ -35,11 +35,6 @@ MODULE_PARM_DESC(debug, "Bitmapped debugging message enable value");
/* This is the time (in jiffies) between invocations of the hardware
* monitor.
- * On Falcon-based NICs, this will:
- * - Check the on-board hardware monitor;
- * - Poll the link state and reconfigure the hardware as necessary.
- * On Siena-based NICs for power systems with EEH support, this will give EEH a
- * chance to start.
*/
static unsigned int efx_monitor_interval = 1 * HZ;
@@ -30,13 +30,6 @@
*
* Only some combinations are supported, depending on NIC type:
*
- * - Falcon supports RX filters matching by {TCP,UDP}/IPv4 4-tuple or
- * local 2-tuple (only implemented for Falcon B0)
- *
- * - Siena supports RX and TX filters matching by {TCP,UDP}/IPv4 4-tuple
- * or local 2-tuple, or local MAC with or without outer VID, and RX
- * default filters
- *
* - Huntington supports filter matching controlled by firmware, potentially
* using {TCP,UDP}/IPv{4,6} 4-tuple or local 2-tuple, local MAC or I/G bit,
* with or without outer and inner VID
@@ -79,9 +79,7 @@ int efx_enqueue_skb_tso(struct efx_tx_queue *tx_queue, struct sk_buff *skb,
/* Decide whether to push a TX descriptor to the NIC vs merely writing
* the doorbell. This can reduce latency when we are adding a single
- * descriptor to an empty queue, but is otherwise pointless. Further,
- * Falcon and Siena have hardware bugs (SF bug 33851) that may be
- * triggered if we don't check this.
+ * descriptor to an empty queue, but is otherwise pointless.
* We use the write_count used for the last doorbell push, to get the
* NIC's view of the tx queue.
*/
@@ -38,8 +38,7 @@
/*
* Loopback test packet structure
*
- * The self-test should stress every RSS vector, and unfortunately
- * Falcon only performs RSS on TCP/UDP packets.
+ * The self-test should stress every RSS vector.
*/
struct efx_loopback_payload {
char pad[2]; /* Ensures ip is 4-byte aligned */
@@ -581,10 +580,6 @@ efx_test_loopback(struct efx_tx_queue *tx_queue,
return 0;
}
-/* Wait for link up. On Falcon, we would prefer to rely on efx_monitor, but
- * any contention on the mac lock (via e.g. efx_mac_mcast_work) causes it
- * to delay and retry. Therefore, it's safer to just poll directly. Wait
- * for link up and any faults to dissipate. */
static int efx_wait_for_link(struct efx_nic *efx)
{
struct efx_link_state *link_state = &efx->link_state;