Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp6251108pxv; Thu, 29 Jul 2021 09:51:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx3by/ae1HLHBLWOZWvs5Bqp1GDWycR2vrpvf5IaydwV7pDTEreKqt11+ty85EZvDGeHqAQ X-Received: by 2002:a92:b745:: with SMTP id c5mr4291553ilm.251.1627577503450; Thu, 29 Jul 2021 09:51:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627577503; cv=none; d=google.com; s=arc-20160816; b=kXOhfpgiwbSW1GcEoXPnr1taMdGWSDeScStGN/ZhWRvD6EORE4eRNOwlB5/aJHP5y5 zDzN7U0a0PUerajFk474Znt/e+icCqKnRaHouVAgOuaH1NA3UQ9BxD39flKD6cP3sPjx H078YuBhJnXWaOU50VK4Qjf0jf8tJHJ4MDpxnQi4i15rSitkmXzFrNJR88Tu/B/vIVIu 50beXBn5vVlvd4isuEEejDBy2sM3AyPTkeUEuPMyTZQKm7l9wXUB0WT+5WJJzoTQEqm3 YSREuk1jTVAkj/UG9NJJBCYTvE4B14ulpjSGt/oXgIPYqvtrnX7hDXLU2bQ+yNEHOLjN I/Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ge2c2dD+EBmDmaGN5nupteoqdj28OTIbcgEuzsesBTw=; b=Hhwcw3L0emWqgmcNfvrVeILnEzPRA4FMMQnNHWtL3fgdsAifU6M5jBVUE5im2e9AqV XNgGuL8cJGlPjh4zTZerPxe+kMd6FrMxd5XUU+5rBJcqeNlhvW+SIIMoM9NZssxicxaI 7mamE+SLbBB4xMPM7475IiPuOGH/534xnnFGQ8ZGKGu2OZizP/cJp6PGuGJQb9iTGchK Yauvte77ZiXilB2uQbKTm+zf8UUpjBeW4ITocDR8I/SP6+WbVzd+ozN0nFvOvshFVnia sbLZElMkmUjbRy3qLkUZ89AtQwKOx2eVykuOYBaiEoB8TeCgz0lO1NkNgeE4pZrz3Vlo FCMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qL2Rj3Ju; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g4si3898674ile.131.2021.07.29.09.51.31; Thu, 29 Jul 2021 09:51:43 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qL2Rj3Ju; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229935AbhG2Que (ORCPT + 99 others); Thu, 29 Jul 2021 12:50:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229556AbhG2Que (ORCPT ); Thu, 29 Jul 2021 12:50:34 -0400 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DD6FC061765; Thu, 29 Jul 2021 09:50:30 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id f13so9035236edq.13; Thu, 29 Jul 2021 09:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ge2c2dD+EBmDmaGN5nupteoqdj28OTIbcgEuzsesBTw=; b=qL2Rj3JukTZAxtcWyetmk0LTL3hs8/mi9vn+JdDmSkmyeRjbMqR9jXg8gFWsv6kGdz O0mVq9BBHW+9GVS+YDVrhRf0mXLlO5vCDryASFucgvyh0dkAlvrfzd/ieoXEO75YfthV P3NThxNT4ZFkznm+Tkruy0vS3BJakX4rGnzOqjRuyu1qC9V8Ydx9GUQnjJbXIy+Y6DOo Jwx+w1uqo7G9P/fIIdEpYI81sGJQaMfU4fn1MlNIs6Uh8wlE1YenINqJN6SFKeF6cmN6 l1l0o1orLp4On4m4sET2NN461fgFveISmPlIFkRWIAH9vXEz16WarCNbpNHwG+kNT+SC a2oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ge2c2dD+EBmDmaGN5nupteoqdj28OTIbcgEuzsesBTw=; b=NApSNNceX5ZCGj1961NQBOXyuM1Ed7PDhy5k3bBD+2XFrFaVt2xhLU/AdnHhvfF57e 1TgXm+FpqdeL6so4uLtxSUu2XWiznLVSXQUZST+EJgjCtVKyFkQNSR9rNQVSe1CVeI6Y 9qU9iCuzG0gwHWrLRZgBotWKl0s0y3h33DrsSUOt1JYxi8LUoz5WKElkKq3TIikGwUCs bozuLZZTQmKuyrUxDKKq0JlNy7c6/8YkxwGI1T8NnZCGEUvVzjFULrhjpmBJikki7cAn dK6+pLuLyiBL0+OqOTVngmh5DU26UNiDaL46o7Q0ghVTU9sI8lnkgjn8xLayEo7VVF0i bt9g== X-Gm-Message-State: AOAM532QB+iAD6vgd0fydb39DOrRw01p5AmuTdxpu8dO6Tr0kCnsfQSl 1qCXuLglKeDxJJTx6sNJj7M= X-Received: by 2002:a05:6402:d63:: with SMTP id ec35mr7069658edb.347.1627577429163; Thu, 29 Jul 2021 09:50:29 -0700 (PDT) Received: from skbuf ([82.76.66.29]) by smtp.gmail.com with ESMTPSA id la23sm1155008ejc.63.2021.07.29.09.50.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jul 2021 09:50:28 -0700 (PDT) Date: Thu, 29 Jul 2021 19:50:27 +0300 From: Vladimir Oltean To: DENG Qingfang Cc: Sean Wang , Landen Chao , Andrew Lunn , Vivien Didelot , Florian Fainelli , "David S. Miller" , Jakub Kicinski , Matthias Brugger , netdev , Linux ARM , "moderated list:ARM/Mediatek SoC support" , linux-kernel Subject: Re: [RFC net-next 2/2] net: dsa: mt7530: trap packets from standalone ports to the CPU Message-ID: <20210729165027.okmfa3ulpd3e6gte@skbuf> References: <20210728175327.1150120-1-dqfext@gmail.com> <20210728175327.1150120-3-dqfext@gmail.com> <20210729152805.o2pur7pp2kpxvvnq@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 30, 2021 at 12:11:45AM +0800, DENG Qingfang wrote: > On Thu, Jul 29, 2021 at 11:28 PM Vladimir Oltean wrote: > > Actually, on second thought... > > If MT7530 supports 8 FIDs and it has 7 ports, then you can assign one > > FID to each standalone port or VLAN-unaware bridge it is a member of. > > The problem is, there is no way to do that.. > > According to the reference manual: > Filter ID is learned automatically from VLAN Table. 0 is the default value if > VLAN Table is not applicable. > > So it is always 0 in VLAN-unaware mode. I have the MT7621 GSW, and sadly this reference manual isn't the best in explaining what is and what is not possible. For example, I am still not clear what is meant by "VID1" and "VID0". Is "VID1" the inner (customer) VLAN tag, and "VID0" the outer (service) VLAN tag, or "VID1" means the actual VLAN ID 1? And the bits 3:1 of VAWD1 (VLAN table access register) indicate a FID field per VLAN. I cannot find the piece that you quoted in this manual. But what I expect to happen for a Transparent Port is that the packets are always classified to that port's PVID, and the VLAN Table is looked up with that PVID. There, it will find the FID, which this driver currently always configures as zero. In my manual's description, in the "Transparent Port" chapter, it does explicitly say: VID0 and VID1 will store PVID as the default VID which is used to look up the VLAN table. So I get the impression that the phrase "the VLAN table is not applicable" is not quite correct, but I might be wrong...