Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2296013pxp; Mon, 21 Mar 2022 16:10:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwDEFkinQtbjzchcYEbmbA2B5edd1LIKWmffNeSkVBOhLeV6DutWxqN6vNFqIc+wLTGQ6mg X-Received: by 2002:a05:6a00:1252:b0:4fa:afcc:7d24 with SMTP id u18-20020a056a00125200b004faafcc7d24mr3489660pfi.85.1647904224978; Mon, 21 Mar 2022 16:10:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647904224; cv=none; d=google.com; s=arc-20160816; b=uPHZKj73ZiX/Ujicq/hJxDje8eccfhS9eigwtQ40Jt77i7uL7q3l+zc1B37pL8wSI3 LyshUaaKyJqqk5TNDytCT3//hIPLvzGiL/Tr7MQnkzQj9nzpGbl2qe0z51P0xOhhEtwD 5JXIlCtJ8A5ItynEPoX6oazQQ41gVR/2yO1cKXVs6qMMyyHLCOLt5AXzsUGfAb3E08ig PGloRdNMj313qGtU+7cWm/yZbyPRVHrq9s5MRUg6BwWnoc4UJ9IlZxuR3m4S7V+g/g4A NBlpU6G5bDRzyqLt6Y1zVkUOwCDaR6wOPGoXdldGHPRCAKvgvW2KYrE4dffpEEX/fZA/ M4WA== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=OYUDCsy57xHSNl4OUE4N+Z2gzfiKjyLuJCQjdlzA2OA=; b=MrSwxa7ms3rPs4nKQW+fTp/Irk8pIDHk3XmwxnZqK5yS+LWIjfhtk04+UtKNOfOcqB eSaNoJUieCNlIH+5IFS17W7G2sv573nP5lP4w7CXBL/lq9dfLJSugCgqqPiZo4FxvDbZ Pur75qKqv5hrP+sIKnHW13lcpRXGAYxVpnCAkj8l94IxBhl0jc7qA7AkH/jFQKsvwGC5 DnL/vDzO+T4lbQ0xf8CluytlEZYiWLBu9+MujcQKY9x2lCZUlCZ2gJEpsVshKEGyAEAM 9jCq8JLjTZdkvrzE3qW5j9IBvfpRHETNLDrmNO79PIabrbXSfxuaKG8ulUBRtmIcY1u7 3v8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=f14wjtNX; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id q4-20020a056a00084400b004fa701bd461si9737820pfk.203.2022.03.21.16.10.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Mar 2022 16:10:24 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=f14wjtNX; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B9D4E6D84C; Mon, 21 Mar 2022 15:08:38 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349337AbiCUOIK (ORCPT + 99 others); Mon, 21 Mar 2022 10:08:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348676AbiCUOA5 (ORCPT ); Mon, 21 Mar 2022 10:00:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F8F33D48F; Mon, 21 Mar 2022 06:58:59 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1F19C612A1; Mon, 21 Mar 2022 13:58:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 109A6C340ED; Mon, 21 Mar 2022 13:58:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871137; bh=saHmvrY9uxdGezIR6fec89oK13Fs/l/1MxLyPHD9tpQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f14wjtNXL7RMQ1CUngUqRSEhktxPmRrQFkD0fCPd5fp4Xkr+q2WvcvfVlAAsVsNJK wXoxqQ9OGpaUlQkmkdbY3Yq4R+G1Qe2vwkDVnipsCJJI4RkieCaQ/4+rQvRBRHQXwP m+5Dr2hRrXUTGuIk9yqJO3vhEXYNWCUJHy/0fjBU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vladimir Oltean , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.10 18/30] net: mscc: ocelot: fix backwards compatibility with single-chain tc-flower offload Date: Mon, 21 Mar 2022 14:52:48 +0100 Message-Id: <20220321133220.173764440@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133219.643490199@linuxfoundation.org> References: <20220321133219.643490199@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vladimir Oltean [ Upstream commit 8e0341aefcc9133f3f48683873284b169581315b ] ACL rules can be offloaded to VCAP IS2 either through chain 0, or, since the blamed commit, through a chain index whose number encodes a specific PAG (Policy Action Group) and lookup number. The chain number is translated through ocelot_chain_to_pag() into a PAG, and through ocelot_chain_to_lookup() into a lookup number. The problem with the blamed commit is that the above 2 functions don't have special treatment for chain 0. So ocelot_chain_to_pag(0) returns filter->pag = 224, which is in fact -32, but the "pag" field is an u8. So we end up programming the hardware with VCAP IS2 entries having a PAG of 224. But the way in which the PAG works is that it defines a subset of VCAP IS2 filters which should match on a packet. The default PAG is 0, and previous VCAP IS1 rules (which we offload using 'goto') can modify it. So basically, we are installing filters with a PAG on which no packet will ever match. This is the hardware equivalent of adding filters to a chain which has no 'goto' to it. Restore the previous functionality by making ACL filters offloaded to chain 0 go to PAG 0 and lookup number 0. The choice of PAG is clearly correct, but the choice of lookup number isn't "as before" (which was to leave the lookup a "don't care"). However, lookup 0 should be fine, since even though there are ACL actions (policers) which have a requirement to be used in a specific lookup, that lookup is 0. Fixes: 226e9cd82a96 ("net: mscc: ocelot: only install TCAM entries into a specific lookup and PAG") Signed-off-by: Vladimir Oltean Link: https://lore.kernel.org/r/20220316192117.2568261-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- drivers/net/ethernet/mscc/ocelot_flower.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mscc/ocelot_flower.c b/drivers/net/ethernet/mscc/ocelot_flower.c index 217e8333de6c..c4c4649b2088 100644 --- a/drivers/net/ethernet/mscc/ocelot_flower.c +++ b/drivers/net/ethernet/mscc/ocelot_flower.c @@ -54,6 +54,12 @@ static int ocelot_chain_to_block(int chain, bool ingress) */ static int ocelot_chain_to_lookup(int chain) { + /* Backwards compatibility with older, single-chain tc-flower + * offload support in Ocelot + */ + if (chain == 0) + return 0; + return (chain / VCAP_LOOKUP) % 10; } @@ -62,7 +68,15 @@ static int ocelot_chain_to_lookup(int chain) */ static int ocelot_chain_to_pag(int chain) { - int lookup = ocelot_chain_to_lookup(chain); + int lookup; + + /* Backwards compatibility with older, single-chain tc-flower + * offload support in Ocelot + */ + if (chain == 0) + return 0; + + lookup = ocelot_chain_to_lookup(chain); /* calculate PAG value as chain index relative to the first PAG */ return chain - VCAP_IS2_CHAIN(lookup, 0); -- 2.34.1