From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78AB4285CA4; Thu, 23 Apr 2026 10:14:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776939269; cv=none; b=tPL/sAbe8Ti0QRLuYdO7gkCPWa2n5vO0VTUXs0Ur8PjXLmKQgQsEbNa68awN1xWnUqdjymxQplNUAScSnvhuHWX0G190DfCkdvtRQ+ZxcLBkkUhfvcjSSaapx+It/Fltvs9k1GnBh7tuVI01nCr0vJ8frGwwHZzUyHEw8zCqMDI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776939269; c=relaxed/simple; bh=n8PIjgIUEEPbYl8wiqKvWUmCj65cJf49TySsuytpK7A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JAC4xzI4oky6EDOr82PN1n1aEXFTC+KXCdP89MbDVcSU1ZOu1nBPjLpwEZSkPaflmHpP3/DfYjoHIpPyQdUhl31fByzEADKYvF0W9gsxc3Jfmxa4/85tthsv61UpXYjQK3HUfVPVE60bwpc+yHF2EfVWHgBq59pyQmLfXIv6vfs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tPjLXDu5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tPjLXDu5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10D7EC2BCAF; Thu, 23 Apr 2026 10:14:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776939269; bh=n8PIjgIUEEPbYl8wiqKvWUmCj65cJf49TySsuytpK7A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tPjLXDu5U98lUgHoOFztzZjJCdypSNHcXrtuJDmG0XbCFaChSeQ100t7L5fCEF8Mr lIX68jwc2X3Z1MQzcBDQk64Je/U3ajk5rM3aArELccP20WwII3W5jLqYFWBafTvC9J 2sTn3ugFy5R2FobE8ilHp+XFIWc7Ck65qWVbH/qjj0/T30h2/gSNYOZAhxNjvQ706m RRPU+Wqc8TNRbSi0xKXw2nBCNyhHrHH6lBT++34BPsIK/tTY0E6x6BlE1wyBcSlPEw cjIxa1BhsnUos6cWRMotJA6k1Gl2Y+LhjyruNa4EdnxsihoWHv2l/a31S4IHch9re1 wI4e/sUcylHNA== From: Simon Horman To: rkannoth@marvell.com Cc: Simon Horman , davem@davemloft.net, edumazet@google.com, linux-kernel@vger.kernel.org, andrew+netdev@lunn.ch, sumang@marvell.com, netdev@vger.kernel.org, dan.carpenter@linaro.org, sgoutham@marvell.com, error27@gmail.com, kuba@kernel.org, pabeni@redhat.com Subject: Re: [PATCH v2 net 01/11] octeontx2-af: npc: cn20k: Propagate MCAM key-type errors on cn20k Date: Thu, 23 Apr 2026 11:01:47 +0100 Message-ID: <20260423100147.908443-2-horms@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260420023442.3295891-2-rkannoth@marvell.com> References: <20260420023442.3295891-2-rkannoth@marvell.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible. For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html --- octeontx2-af: npc: cn20k: Propagate MCAM key-type errors on cn20k This patch converts several cn20k NPC functions from void to int return types to propagate MCAM key-type lookup errors. It adds error checking for npc_mcam_idx_2_key_type() and threads these errors through the cn20k MCAM handlers. Link: https://lore.kernel.org/netdev/adiQJvuKlEhq2ILx@stanley.mountain/ > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c > index 7291fdb89b03..18d70f4527d1 100644 > --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c > +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c [ ... ] > @@ -1415,9 +1435,9 @@ int rvu_mbox_handler_npc_cn20k_mcam_alloc_and_write_entry(struct rvu *rvu, > else > nix_intf = pfvf->nix_rx_intf; > > - npc_cn20k_config_mcam_entry(rvu, blkaddr, entry, nix_intf, > - &req->entry_data, req->enable_entry, > - req->hw_prio, req->req_kw_type); > + rc = npc_cn20k_config_mcam_entry(rvu, blkaddr, entry, nix_intf, > + &req->entry_data, req->enable_entry, > + req->hw_prio, req->req_kw_type); > > mutex_unlock(&mcam->lock); > > rsp->entry = entry_rsp.entry; > return 0; Does this function need to return rc instead of 0? If npc_cn20k_config_mcam_entry() fails (for example, due to an invalid key type), the function still returns success to the caller. The mailbox response indicates the entry was successfully allocated and configured, but the hardware entry may be in an undefined state. [ ... ]