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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C5DFECAAD2 for ; Mon, 29 Aug 2022 16:13:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229926AbiH2QN0 (ORCPT ); Mon, 29 Aug 2022 12:13:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230241AbiH2QNX (ORCPT ); Mon, 29 Aug 2022 12:13:23 -0400 Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8641844D7; Mon, 29 Aug 2022 09:13:17 -0700 (PDT) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 3FDD418848CD; Mon, 29 Aug 2022 16:13:15 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 36E6B25032B7; Mon, 29 Aug 2022 16:13:15 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id 26D919EC0004; Mon, 29 Aug 2022 16:13:15 +0000 (UTC) X-Screener-Id: 413d8c6ce5bf6eab4824d0abaab02863e8e3f662 MIME-Version: 1.0 Date: Mon, 29 Aug 2022 18:13:14 +0200 From: netdev@kapio-technology.com To: Ido Schimmel Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, Florian Fainelli , Andrew Lunn , Vivien Didelot , Vladimir Oltean , Eric Dumazet , Paolo Abeni , Kurt Kanzenbach , Hauke Mehrtens , Woojung Huh , UNGLinuxDriver@microchip.com, Sean Wang , Landen Chao , DENG Qingfang , Matthias Brugger , Claudiu Manoil , Alexandre Belloni , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Nikolay Aleksandrov , Shuah Khan , Christian Marangi , Daniel Borkmann , Yuwei Wang , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, bridge@lists.linux-foundation.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v5 net-next 6/6] selftests: forwarding: add test of MAC-Auth Bypass to locked port tests In-Reply-To: References: <20220826114538.705433-1-netdev@kapio-technology.com> <20220826114538.705433-7-netdev@kapio-technology.com> <7654860e4d7d43c15d482c6caeb6a773@kapio-technology.com> <2967ccc234bb672f5440a4b175b73768@kapio-technology.com> <9e1a9eb218bbaa0d36cb98ff5d4b97d7@kapio-technology.com> <69db7606896c77924c11a6c175c4b1a6@kapio-technology.com> User-Agent: Gigahost Webmail Message-ID: X-Sender: netdev@kapio-technology.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2022-08-29 18:03, Ido Schimmel wrote: > On Mon, Aug 29, 2022 at 05:08:23PM +0200, netdev@kapio-technology.com > wrote: >> On 2022-08-29 16:37, Ido Schimmel wrote: >> > On Mon, Aug 29, 2022 at 02:04:42PM +0200, netdev@kapio-technology.com >> > wrote: >> > > On 2022-08-29 13:32, Ido Schimmel wrote: >> > > Port association is needed for MAB to work at all on mv88e6xxx, but >> > > for >> > > 802.1X port association is only needed for dynamic ATU entries. >> > >> > Ageing of dynamic entries in the bridge requires learning to be on as >> > well, but in these test cases you are only using static entries and >> > there is no reason to enable learning in the bridge for that. I prefer >> > not to leak this mv88e6xxx implementation detail to user space and >> > instead have the driver enable port association based on whether >> > "learning" or "mab" is on. >> > >> >> Then it makes most sense to have the mv88e6xxx driver enable port >> association when then port is locked, as it does now. > > As you wish, but like you wrote "802.1X port association is only needed > for dynamic ATU entries" and in this case user space needs to enable > learning (for refresh only) so you can really key off learning on > "learning || mab". User space can decide to lock the port and work with > static entries and then learning is not required. I will of course remove all "learning on" in the selftests, which is what I think you are referring to. In the previous I am referring to the code in the driver itself which I understand shall turn on port association with locked ports, e.g. no need for "learning on" when using the feature in general outside selftests...