Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: DENG Qingfang <dqfext@gmail.com>
Cc: Sean Wang <sean.wang@mediatek.com>,
Landen Chao <Landen.Chao@mediatek.com>,
Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
netdev <netdev@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC net-next 2/2] net: dsa: mt7530: trap packets from standalone ports to the CPU
Date: Thu, 29 Jul 2021 19:50:27 +0300 [thread overview]
Message-ID: <20210729165027.okmfa3ulpd3e6gte@skbuf> (raw)
In-Reply-To: <CALW65jbHwRhekX=7xoFvts2m7xTRM4ti9zpTiah8ed0n0fCrRg@mail.gmail.com>
On Fri, Jul 30, 2021 at 12:11:45AM +0800, DENG Qingfang wrote:
> On Thu, Jul 29, 2021 at 11:28 PM Vladimir Oltean <olteanv@gmail.com> 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...
next prev parent reply other threads:[~2021-07-29 16:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-28 17:53 [RFC net-next 0/2] mt7530 software fallback bridging fix DENG Qingfang
2021-07-28 17:53 ` [RFC net-next 1/2] net: dsa: tag_mtk: skip address learning on transmit to standalone ports DENG Qingfang
2021-07-28 18:37 ` Vladimir Oltean
2021-07-30 16:24 ` Vladimir Oltean
2021-07-30 17:32 ` DENG Qingfang
2021-07-30 17:39 ` Vladimir Oltean
2021-07-30 17:41 ` Vladimir Oltean
2021-07-30 17:58 ` DENG Qingfang
2021-07-30 19:00 ` DENG Qingfang
2021-07-30 19:07 ` Vladimir Oltean
2021-07-30 19:25 ` DENG Qingfang
2021-07-30 19:30 ` Vladimir Oltean
2021-07-28 17:53 ` [RFC net-next 2/2] net: dsa: mt7530: trap packets from standalone ports to the CPU DENG Qingfang
2021-07-28 18:47 ` Vladimir Oltean
2021-07-29 15:28 ` Vladimir Oltean
2021-07-29 16:11 ` DENG Qingfang
2021-07-29 16:50 ` Vladimir Oltean [this message]
2021-07-30 15:45 ` DENG Qingfang
2021-07-30 15:58 ` DENG Qingfang
2021-07-30 16:18 ` Vladimir Oltean
2021-07-30 17:21 ` DENG Qingfang
2021-07-30 17:35 ` Vladimir Oltean
2021-07-30 17:51 ` DENG Qingfang
2021-07-28 18:08 ` [RFC net-next 0/2] mt7530 software fallback bridging fix Vladimir Oltean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210729165027.okmfa3ulpd3e6gte@skbuf \
--to=olteanv@gmail.com \
--cc=Landen.Chao@mediatek.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dqfext@gmail.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sean.wang@mediatek.com \
--cc=vivien.didelot@gmail.com \
--subject='Re: [RFC net-next 2/2] net: dsa: mt7530: trap packets from standalone ports to the CPU' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).