[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <471b75b6971dc5fa19984b43042199dec41ca9f3.camel@siemens.com>
Date: Thu, 6 Nov 2025 16:26:29 +0000
From: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
To: "olteanv@...il.com" <olteanv@...il.com>
CC: "andrew@...n.ch" <andrew@...n.ch>, "robh@...nel.org" <robh@...nel.org>,
"lxu@...linear.com" <lxu@...linear.com>, "john@...ozen.org"
<john@...ozen.org>, "davem@...emloft.net" <davem@...emloft.net>,
"yweng@...linear.com" <yweng@...linear.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
"edumazet@...gle.com" <edumazet@...gle.com>, "bxu@...linear.com"
<bxu@...linear.com>, "devicetree@...r.kernel.org"
<devicetree@...r.kernel.org>, "ajayaraman@...linear.com"
<ajayaraman@...linear.com>, "fchan@...linear.com" <fchan@...linear.com>,
"conor+dt@...nel.org" <conor+dt@...nel.org>, "daniel@...rotopia.org"
<daniel@...rotopia.org>, "hauke@...ke-m.de" <hauke@...ke-m.de>,
"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "horms@...nel.org"
<horms@...nel.org>, "kuba@...nel.org" <kuba@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "jpovazanec@...linear.com"
<jpovazanec@...linear.com>, "linux@...linux.org.uk" <linux@...linux.org.uk>
Subject: Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear
GSW1xx switch family
Hi Vladimir,
On Thu, 2025-11-06 at 17:27 +0200, Vladimir Oltean wrote:
> > The remaining failing test cases are:
> > TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address [FAIL]
> > reception succeeded, but should have failed
> > TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti [FAIL]
> > reception succeeded, but should have failed
> >
> > So far I didn't notice any problems with untagged read-word IP traffic over
> > GSW145 ports.
> >
> > Do you have a suggestion what could I check further regarding the failing
> > test cases? As I understood, all of them pass on your side?
>
> These failures mean that the test thinks the port implements IFF_UNICAST_FLT,
> yet it doesn't drop unregistered traffic.
>
> [ $no_unicast_flt = true ] && should_receive=true || should_receive=false
> check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address" \
> "$smac > $UNKNOWN_UC_ADDR1, ethertype IPv4 (0x0800)" \
> $should_receive "$test_name"
>
> But DSA doesn't report IFF_UNICAST_FLT for this switch, because it doesn't fulfill
> the dsa_switch_supports_uc_filtering() requirements. So should_receive should have
> been true, and the question becomes why does this code snippet set no_unicast_flt=false:
>
> vlan_over_bridged_port()
> {
> local no_unicast_flt=true
> local vlan_filtering=$1
> local skip_ptp=false
>
> # br_manage_promisc() will not force a single vlan_filtering port to
> # promiscuous mode, so we should still expect unicast filtering to take
> # place if the device can do it.
> if [ $(has_unicast_flt $h2) = yes ] && [ $vlan_filtering = 1 ]; then
> no_unicast_flt=false
> fi
>
> Because IFF_UNICAST_FLT is not a UAPI-visible property, has_unicast_flt() does
> an indirect check: it creates a macvlan upper with a different MAC address than
> the physical interface's, and this results in a dev_uc_add() in the kernel.
> If the unicast address is non-empty but the device doesn't have IFF_UNICAST_FLT,
> __dev_set_rx_mode() makes the interface promiscuous, which has_unicast_flt()
> then tests.
here is the corresponding kernel log preceding the failing test cases, maybe it
might help?
[ 539.836062] mxl-gsw1xx 8000f00.mdio:00 lan1: left allmulticast mode
[ 539.845053] am65-cpsw-nuss 8000000.ethernet eth0: left allmulticast mode
[ 539.853401] br0: port 1(lan1) entered disabled state
[ 545.641001] am65-cpsw-nuss 8000000.ethernet: Removing vlan 1 from vlan filter
[ 546.075411] mxl-gsw1xx 8000f00.mdio:00 lan1: Link is Down
[ 546.666944] mxl-gsw1xx 8000f00.mdio:00 lan0: Link is Down
[ 547.779308] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode
[ 548.803903] mxl-gsw1xx 8000f00.mdio:00 lan0: configuring for phy/internal link mode
[ 549.561829] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode
[ 550.366300] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode
[ 550.395032] br0: port 1(lan1) entered blocking state
[ 550.401063] br0: port 1(lan1) entered disabled state
[ 550.406470] mxl-gsw1xx 8000f00.mdio:00 lan1: entered allmulticast mode
[ 550.413868] am65-cpsw-nuss 8000000.ethernet eth0: entered allmulticast mode
[ 550.440111] am65-cpsw-nuss 8000000.ethernet: Adding vlan 1 to vlan filter
[ 550.465479] am65-cpsw-nuss 8000000.ethernet: Adding vlan 100 to vlan filter
[ 552.519232] mxl-gsw1xx 8000f00.mdio:00 lan1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 552.530513] br0: port 1(lan1) entered blocking state
[ 552.536463] br0: port 1(lan1) entered forwarding state
[ 552.999330] mxl-gsw1xx 8000f00.mdio:00 lan0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 581.899262] lan1.100: entered promiscuous mode
[ 592.995574] lan1.100: left promiscuous mode
[ 596.665022] lan1.100: entered allmulticast mode
[ 607.789778] lan1.100: left allmulticast mode
--
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to macvlan MAC address [ OK ]
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address [FAIL]
reception succeeded, but should have failed
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, promisc [ OK ]
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti [FAIL]
reception succeeded, but should have failed
--
Alexander Sverdlin
Siemens AG
www.siemens.com
Powered by blists - more mailing lists