From patchwork Mon Oct 26 04:18:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Chan X-Patchwork-Id: 11855673 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,MIME_HEADER_CTYPE_ONLY,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,T_TVD_MIME_NO_HEADERS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63B29C56201 for ; Mon, 26 Oct 2020 04:18:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 13CDC22247 for ; Mon, 26 Oct 2020 04:18:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="CERhcMSP" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1421018AbgJZESj (ORCPT ); Mon, 26 Oct 2020 00:18:39 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:42268 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1420967AbgJZESi (ORCPT ); Mon, 26 Oct 2020 00:18:38 -0400 Received: by mail-pl1-f193.google.com with SMTP id t22so4115059plr.9 for ; Sun, 25 Oct 2020 21:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=kHZxykr3MBtf9fNtmterRp5McBAJfcZeT+TwwHws64w=; b=CERhcMSPoqKwEpCQkGYQVels6Utq+3dAwWapNYphF1hbl8QrAHVuLVa9y46qhjCA+d FrwAiIabegfDMX5jRoWe3mMxMri0snlvlNmfYjnlp+FfKa3EthxMn/H+bPgi9bzgNIMB lqWZBlAjSW1sFA6ck7bcMiB0uFX03LJamHvC8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=kHZxykr3MBtf9fNtmterRp5McBAJfcZeT+TwwHws64w=; b=bm+q/PMJwlroFM0YWxaDVt16WvjNglYVn0JZEoEf2SBmr+q9J8yL3rLLHuOnv19SG/ f2cy79qHxX8L/J39xwfTz74gpnBlPDQCzPsXPkfvJI9v78YdCgAB+VldJtnnJ+PGXjO6 pWlJWiifLHHOhP10tR9ZGvwyjhrlNRVNntDy/ESYOaPTUt2ragF5rTS+Daw7yI0mHO1j kejFDSHDAAvdEFMNWEAx9xGpshjfhj9Avz/W99gydkT+RtVMXuvD100yOifjRxTGnaNh LMku4C7cPfOWUDjHnEkIRSfqJGgxTatOc+TiNh+ARoduvNXLgh56FprDLsben3oLCeye RWxg== X-Gm-Message-State: AOAM532BWjWEG8qKtNbaNeF1VOkONPJPBzcSBGtQroorciUO1GS2CtVt tZPjooa71ePze6aQUVDNq1juQg== X-Google-Smtp-Source: ABdhPJwIbiyxDTUbEZfXZB4pCiJ9h9uU8us/tV99Tvz4K7G859oa8HthM3BdN6fGlQHbju+nsTDRgA== X-Received: by 2002:a17:902:8502:b029:d5:b4f4:8555 with SMTP id bj2-20020a1709028502b02900d5b4f48555mr12912230plb.76.1603685917100; Sun, 25 Oct 2020 21:18:37 -0700 (PDT) Received: from localhost.swdvt.lab.broadcom.net ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id 10sm11505835pjt.50.2020.10.25.21.18.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Oct 2020 21:18:36 -0700 (PDT) From: Michael Chan To: kuba@kernel.org Cc: netdev@vger.kernel.org, gospo@broadcom.com, Vasundhara Volam Subject: [PATCH net 5/5] bnxt_en: Send HWRM_FUNC_RESET fw command unconditionally. Date: Mon, 26 Oct 2020 00:18:21 -0400 Message-Id: <1603685901-17917-6-git-send-email-michael.chan@broadcom.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1603685901-17917-1-git-send-email-michael.chan@broadcom.com> References: <1603685901-17917-1-git-send-email-michael.chan@broadcom.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org From: Vasundhara Volam In the AER or firmware reset flow, if we are in fatal error state or if pci_channel_offline() is true, we don't send any commands to the firmware because the commands will likely not reach the firmware and most commands don't matter much because the firmware is likely to be reset imminently. However, the HWRM_FUNC_RESET command is different and we should always attempt to send it. In the AER flow for example, the .slot_reset() call will trigger this fw command and we need to try to send it to effect the proper reset. Fixes: b340dc680ed4 ("bnxt_en: Avoid sending firmware messages when AER error is detected.") Reviewed-by: Edwin Peer Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c index 0165f70dba74..7975f59735d6 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c @@ -4352,7 +4352,8 @@ static int bnxt_hwrm_do_send_msg(struct bnxt *bp, void *msg, u32 msg_len, u32 bar_offset = BNXT_GRCPF_REG_CHIMP_COMM; u16 dst = BNXT_HWRM_CHNL_CHIMP; - if (BNXT_NO_FW_ACCESS(bp)) + if (BNXT_NO_FW_ACCESS(bp) && + le16_to_cpu(req->req_type) != HWRM_FUNC_RESET) return -EBUSY; if (msg_len > BNXT_HWRM_MAX_REQ_LEN) {