From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D9808C3DA7A for ; Fri, 6 Jan 2023 10:48:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:Cc:To:From :Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Ts56Hk02JxjWJPhu4lswtmEo7yU95qQjVFN9a1dWJPE=; b=B6ge2vkTVfta0UnIawyTO+AIP8 QlNa3IzcKSjMtJ1bc17kMU6wfgMWZQ3CgyWVS/gMpWWeA8LSJdDVbXlZmU0aSEfyNrqjgbBaRfoA8 IcCVaEw+Ht6TOVRhcjHcvq4TyCeQ3XB1dd7RYgg8+yD0pLMS2VEeCeZY579+iSxz82eoCZZuitcbg VFFLnG2/6nwvZBpwnwUIua8vG+gvdJmTS2EMXzhw032oHuefNj9qNe5MGwb/lHLETxvFqPiurnd0z cXTNpIfNVUWEw45h3oRRH5EdPT4v2xwD7CNpWs1w+VPd/IaFNVdsqhcX1SLZ8OsdqUHEg2UtRegn1 jFn+Z3JA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pDkFg-007Y3U-TA; Fri, 06 Jan 2023 10:47:09 +0000 Received: from 0001.3ffe.de ([159.69.201.130] helo=mail.3ffe.de) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pDkFc-007Xz0-VI for linux-arm-kernel@lists.infradead.org; Fri, 06 Jan 2023 10:47:06 +0000 Received: from 3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id A1AA7125C; Fri, 6 Jan 2023 11:46:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1673002017; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2sAgKVw2R59p7zF72zbcRbRDTSb5XaO8aLxzjSwbQ5E=; b=kkMunGl6kfvzkLRQNl9fJNG4bpD3Yh9+Iw8tcAc/PJDpBVjwJqJlttqS4LB/6a9UDOzHg1 PHxXpkM19VIzqhEFfnT8L0N9fajkdc3sG0O74CHcjJy/EWnT8ZWzGKN6niptWxs3byMIul y2eEjxNT35nM0Bwi3euwG40JL+p5H+79wLccWExtbIUiKkvbbCPsoabJGP/er3Qiu4Va6O +HR9NOaGatdCuTbjTJp2bjgM6/p6ranApKmYmQwx/o2Ow2nwsvgl5wibraJaP9OSfxIe5W He28n858M2gbBw8ZMyVleNeTHzsuc+S5fqa5evTqQkAqvXi4k5VKHQ4+hxK1dg== MIME-Version: 1.0 Date: Fri, 06 Jan 2023 11:46:57 +0100 From: Michael Walle To: Steen Hegelund Cc: "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , UNGLinuxDriver@microchip.com, Randy Dunlap , Casper Andersson , Russell King , Wan Jiabing , Nathan Huckleberry , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Daniel Machon , Horatiu Vultur , Lars Povlsen , Dan Carpenter Subject: Re: [PATCH net-next v2 0/8] Add support for two classes of VCAP rules In-Reply-To: References: <20230106085317.1720282-1-steen.hegelund@microchip.com> <35a9ff9fa0980e1e8542d338c6bf1e0c@walle.cc> User-Agent: Roundcube Webmail/1.4.13 Message-ID: <40eea59265ce70a80ca61164608f4739@walle.cc> X-Sender: michael@walle.cc X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230106_024705_311197_E06C091D X-CRM114-Status: GOOD ( 25.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, >> Wouldn't it make more sense, to fix the regression via net (and >> a Fixes: tag) and then make that stuff work without tc? Maybe >> the fix is just reverting the commits. > > I have discussed this again with Horatiu and I have the following > suggestion of > how to proceed: > > 1) Create a small LAN966x specific patch for net (see below for the two > possible > variants). > > 2) Continue with a net-next V3 without any 'Fixes' tags on top of the > patch in > (1) when it becomes available in net-next. Sounds good. [coming back to this after writing the response below, so see there for more context] When do the patches from net become available in net-next? Only after a merge window? If so, depending on the solution for (1) you'd have two "in-between" kernel versions (v6.2 and v6.3). > The LAN966x patch for net (with a Fixes tag) could contain either: > > a) No check on enabled lookup > > Removal of the check for enabled lookups: > > - if (!ANA_VCAP_S2_CFG_ENA_GET(val)) > - return -ENOENT; > > This will remove the error that you have seen, but will still > require a > matchall rule to enable the PTP rules. This is compatible with the > TC > framework. > > b) Always enable lookups > > Enable the lookups at startup. > Remove the lookup enable check as above. > > This will make the PTP rules (and any other rules) work even without > the > matchall rule to enable them. It its not ideal, but solves the > problem that > you have been experiencing without the 'TC magic' > > The V3 in net-next will provide the full solution. > > I expect that you might prefer the b) version. I *assume* linuxptp would have worked in my case (no bridge interface) before Horatiu patches. As mentioned before, I haven't really tested it. Does that mean with a) the error is gone and linuxptp is working as before? If so, I'm also fine with a). Honestly, now that there is a good solution in future kernels, I don't care toooo much about that one particular kernel. Other users might disagree though ;) I just want to point out that right now you have some kind of in-between kernel with 6.2: <=6.1 linuxptp working (but not on bridged ports) 6.2 linuxptp working only with tc magic 6.3 linuxptp working Therefore, I've raised the question if it's also viable to just revert the former changes for 6.2. The you'd have a clean transition. -michael _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel