idpf: fix minor controlq issues
authorAlan Brady <alan.brady@intel.com>
Thu, 22 Feb 2024 19:04:40 +0000 (11:04 -0800)
committerTony Nguyen <anthony.l.nguyen@intel.com>
Mon, 4 Mar 2024 17:48:33 +0000 (09:48 -0800)
While we're here improving virtchnl we can include two minor fixes for
the lower level ctrlq flow.

This adds a memory barrier to idpf_post_rx_buffs before we update tail
on the controlq.  We should make sure our writes have had a chance to
finish before we tell HW it can touch them.

This also removes some defensive programming in idpf_ctrlq_recv. The
caller should not be using a num_q_msg value of zero or more than the
ring size and it's their responsibility to call functions sanely.

Tested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: Alan Brady <alan.brady@intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
drivers/net/ethernet/intel/idpf/idpf_controlq.c

index c7f43d2fcd136e94e3d4a3c3c1c2b148e44718d1..4849590a5591f18fbb2076f5f928a1a8771ab812 100644 (file)
@@ -516,6 +516,8 @@ post_buffs_out:
                        /* Wrap to end of end ring since current ntp is 0 */
                        cq->next_to_post = cq->ring_size - 1;
 
+               dma_wmb();
+
                wr32(hw, cq->reg.tail, cq->next_to_post);
        }
 
@@ -546,11 +548,6 @@ int idpf_ctlq_recv(struct idpf_ctlq_info *cq, u16 *num_q_msg,
        int err = 0;
        u16 i;
 
-       if (*num_q_msg == 0)
-               return 0;
-       else if (*num_q_msg > cq->ring_size)
-               return -EBADR;
-
        /* take the lock before we start messing with the ring */
        mutex_lock(&cq->cq_lock);