Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp939755pxb; Thu, 9 Sep 2021 15:51:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhHxc37Xqr09yr3lxu0mGLS3CTpwdQo7LTZmXx6lutU6phjG3FrxsqANztunT2zhEvxmsb X-Received: by 2002:aa7:c3cb:: with SMTP id l11mr4797405edr.310.1631227875677; Thu, 09 Sep 2021 15:51:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631227875; cv=none; d=google.com; s=arc-20160816; b=W3fTmvK1alx09vPLTacLiAJE2wi/7WfKdphjWWnRilyqWUGDcaDhUIVuTXhZ1KUoxj PypYqiYZc5Box4x6eQkiRxE3ru9T7Sdr9GXRWD1XnzEQdiioslDD2oQcZN3c768C7VGL jGVCTZN9kvnqouPPKzkJ2yDefa4bN9lzGN+p2oYK56sHLS7iuvtNZljOp3GzY2mx16JS s727to5lS3FYJ9qSG2EbsA7gqaYShBZ7sgO6w95XNIPkh9KtTnOQON3aMtoJ+GHbrqQe 3yNo2uuiBCLSjIRzQ7GvGCwFLj2ci+iLQcwYieT+wIgCeK8cf3mz0eIq3n9qrvyPvKhX a9nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=I1vZf0gbT2MOtENEdCeU8AH8WzbXJubn9VPdsJo2Lxc=; b=yR2XaCVH5uBClaObKiNWw/XYN06RLArHyB1qeWkbNUQAzk+QkH92I44ha8YFCgUKon uYkBtzStUjQaLfqAjXjh2kgrfuuI6LHUwTxcXDLVyijPUGhaol7tbAaPb5hQ8+jug+d3 E7XYpa5d2U2Wf1C4DiSYr9RuWn9xV+K+hh9OMEIJSDz+LxpPeM18AJRsULz5FaTryR6a 4EZ2SDy4Tbojo+kKKmkj42xGad8B59t840FSD+OrLhp/Zf6ctnaOuTKfA3QAyy1ksPDi kp8F/vUgXvhtBwQtWzRO76eRkzJOnBfArkO+WP7rJj0IIpZVtn4nmIMoAkdia7DPF2bL pHIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d16si3243653ejm.114.2021.09.09.15.50.52; Thu, 09 Sep 2021 15:51:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343796AbhIIWfW (ORCPT + 99 others); Thu, 9 Sep 2021 18:35:22 -0400 Received: from mga18.intel.com ([134.134.136.126]:4888 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237888AbhIIWfL (ORCPT ); Thu, 9 Sep 2021 18:35:11 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10102"; a="208037405" X-IronPort-AV: E=Sophos;i="5.85,281,1624345200"; d="scan'208";a="208037405" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2021 15:34:01 -0700 X-IronPort-AV: E=Sophos;i="5.85,281,1624345200"; d="scan'208";a="466778996" Received: from dmert-dev.jf.intel.com ([10.166.241.5]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2021 15:33:59 -0700 From: Dave Ertman To: davem@davemloft.net, kuba@kernel.org Cc: yongxin.liu@windriver.com, shiraz.saleem@intel.com, anthony.l.nguyen@intel.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, jesse.brandeburg@intel.com, intel-wired-lan@lists.osuosl.org, leon@kernel.org, linux-rdma@vger.kernel.org, jgg@ziepe.ca, david.m.ertman@intel.com Subject: [PATCH RESEND net] ice: Correctly deal with PFs that do not support RDMA Date: Thu, 9 Sep 2021 08:12:23 -0700 Message-Id: <20210909151223.572918-1-david.m.ertman@intel.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org There are two cases where the current PF does not support RDMA functionality. The first is if the NVM loaded on the device is set to not support RDMA (common_caps.rdma is false). The second is if the kernel bonding driver has included the current PF in an active link aggregate. When the driver has determined that this PF does not support RDMA, then auxiliary devices should not be created on the auxiliary bus. Without a device on the auxiliary bus, even if the irdma driver is present, there will be no RDMA activity attempted on this PF. Currently, in the reset flow, an attempt to create auxiliary devices is performed without regard to the ability of the PF. There needs to be a check in ice_aux_plug_dev (as the central point that creates auxiliary devices) to see if the PF is in a state to support the functionality. When disabling and re-enabling RDMA due to the inclusion/removal of the PF in a link aggregate, we also need to set/clear the bit which controls auxiliary device creation so that a reset recovery in a link aggregate situation doesn't try to create auxiliary devices when it shouldn't. Fixes: f9f5301e7e2d ("ice: Register auxiliary device to provide RDMA") Reported-by: Yongxin Liu Signed-off-by: Dave Ertman Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice.h | 2 ++ drivers/net/ethernet/intel/ice/ice_idc.c | 6 ++++++ 2 files changed, 8 insertions(+) diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h index eadcb9958346..3c4f08d20414 100644 --- a/drivers/net/ethernet/intel/ice/ice.h +++ b/drivers/net/ethernet/intel/ice/ice.h @@ -695,6 +695,7 @@ static inline void ice_set_rdma_cap(struct ice_pf *pf) { if (pf->hw.func_caps.common_cap.rdma && pf->num_rdma_msix) { set_bit(ICE_FLAG_RDMA_ENA, pf->flags); + set_bit(ICE_FLAG_AUX_ENA, pf->flags); ice_plug_aux_dev(pf); } } @@ -707,5 +708,6 @@ static inline void ice_clear_rdma_cap(struct ice_pf *pf) { ice_unplug_aux_dev(pf); clear_bit(ICE_FLAG_RDMA_ENA, pf->flags); + clear_bit(ICE_FLAG_AUX_ENA, pf->flags); } #endif /* _ICE_H_ */ diff --git a/drivers/net/ethernet/intel/ice/ice_idc.c b/drivers/net/ethernet/intel/ice/ice_idc.c index 1f2afdf6cd48..adcc9a251595 100644 --- a/drivers/net/ethernet/intel/ice/ice_idc.c +++ b/drivers/net/ethernet/intel/ice/ice_idc.c @@ -271,6 +271,12 @@ int ice_plug_aux_dev(struct ice_pf *pf) struct auxiliary_device *adev; int ret; + /* if this PF doesn't support a technology that requires auxiliary + * devices, then gracefully exit + */ + if (!ice_is_aux_ena(pf)) + return 0; + iadev = kzalloc(sizeof(*iadev), GFP_KERNEL); if (!iadev) return -ENOMEM; -- 2.31.1