[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251106172958.jjfr3jbzlyexmidg@skbuf>
Date: Thu, 6 Nov 2025 19:29:58 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: "Sverdlin, Alexander" <alexander.sverdlin@...mens.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
On Thu, Nov 06, 2025 at 04:36:55PM +0000, Sverdlin, Alexander wrote:
> Hi Vladimir,
>
> On Thu, 2025-11-06 at 17:26 +0100, Alexander Sverdlin 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
>
> does the following help?
>
> # dev=lan1
> # ip link set $dev up
> [ 2005.688205] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode
> [ 2005.714288] 8021q: adding VLAN 0 to HW filter on device lan1
> # ip link add link $dev name macvlan-tmp type macvlan mode private
> # ip l show lan1
> 4: lan1@...0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
> link/ether 00:a0:03:ea:fe:b7 brd ff:ff:ff:ff:ff:ff
> # ip l
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1000
> link/ether c0:d6:0a:e6:89:9e brd ff:ff:ff:ff:ff:ff
> 3: lan0@...0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
> link/ether 00:a0:03:ea:fe:b6 brd ff:ff:ff:ff:ff:ff
> 4: lan1@...0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
> link/ether 00:a0:03:ea:fe:b7 brd ff:ff:ff:ff:ff:ff
> 5: lan2@...0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether 00:a0:03:ea:fe:b8 brd ff:ff:ff:ff:ff:ff
> 6: lan3@...0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether 00:a0:03:ea:fe:b9 brd ff:ff:ff:ff:ff:ff
> 7: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether 00:a0:03:ea:fe:ba brd ff:ff:ff:ff:ff:ff
> 8: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether 96:f1:ca:89:bc:b0 brd ff:ff:ff:ff:ff:ff
> 60: macvlan-tmp@...1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether 9e:07:e8:7c:9d:99 brd ff:ff:ff:ff:ff:ff
> # ip link set macvlan-tmp address 00:a0:03:ea:fe:b8
> # ip link set macvlan-tmp up
> [ 2109.392322] 8021q: adding VLAN 0 to HW filter on device macvlan-tmp
> # ip -j -d link show dev $dev | jq -r '.[].promiscuity'
> 2
> # ip -j -d link show dev $dev
> [{"ifindex":4,"link":"eth0","ifname":"lan1","flags":["NO-CARRIER","BROADCAST","MULTICAST","PROMISC","UP"],"mtu":1500,"qdisc":"noqueue","operstate":"DOWN","linkmode":"DEFAULT","group":"defau]
> # ip -d link show dev $dev
> 4: lan1@...0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
> link/ether 00:a0:03:ea:fe:b7 brd ff:ff:ff:ff:ff:ff promiscuity 2 allmulti 0 minmtu 68 maxmtu 2378
> dsa conduit eth0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 gso_ipv4_max_size 65536 gro
It partially does, yes. The promiscuity is 2, which suggests it was
already 1 when has_unicast_flt() started to run. The function is not
written to expect that to happen. Although I don't yet understand why
lan1 originally entered promiscuous mode - that is not in your logs.
This is a separate environment from the selftest with the commands ran
manually, no? Because you can just run the selftest with "bash -x".
Powered by blists - more mailing lists