From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Miller <davem@davemloft.net>
Subject: Re: [PATCH net 1/1] qlcnic: fix Tx descriptor corruption on 82xx
 devices
Date: Sat, 29 Sep 2018 11:47:13 -0700 (PDT)
Message-ID: <20180929.114713.2223247016931278384.davem@davemloft.net>
References: <20180926194110.28043-1-shahed.shaikh@cavium.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netdev@vger.kernel.org, Manish.Chopra@cavium.com,
        Dept-GELinuxNICDev@cavium.com
To: shahed.shaikh@cavium.com
Return-path: <netdev-owner@vger.kernel.org>
Received: from shards.monkeyblade.net ([23.128.96.9]:57102 "EHLO
        shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1727569AbeI3BQq (ORCPT
        <rfc822;netdev@vger.kernel.org>); Sat, 29 Sep 2018 21:16:46 -0400
In-Reply-To: <20180926194110.28043-1-shahed.shaikh@cavium.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

From: Shahed Shaikh <shahed.shaikh@cavium.com>
Date: Wed, 26 Sep 2018 12:41:10 -0700

> In regular NIC transmission flow, driver always configures MAC using
> Tx queue zero descriptor as a part of MAC learning flow.
> But with multi Tx queue supported NIC, regular transmission can occur on
> any non-zero Tx queue and from that context it uses
> Tx queue zero descriptor to configure MAC, at the same time TX queue
> zero could be used by another CPU for regular transmission
> which could lead to Tx queue zero descriptor corruption and cause FW
> abort.
> 
> This patch fixes this in such a way that driver always configures
> learned MAC address from the same Tx queue which is used for
> regular transmission.
> 
> Fixes: 7e2cf4feba05 ("qlcnic: change driver hardware interface mechanism")
> Signed-off-by: Shahed Shaikh <shahed.shaikh@cavium.com>

Applied and queued up for -stable.