On 30/06/2019 03:13, vtolkm@gmail.com wrote:

On 30/06/2019 02:37, vtolkm@gmail.com wrote:

quoted

On 30/06/2019 01:23, vtolkm@gmail.com wrote:

quoted

On 30/06/2019 01:11, Andrew Lunn wrote:

quoted

On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:

quoted

On 30/06/2019 00:49, Andrew Lunn wrote:

quoted

On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:

quoted

* DSA MV88E6060
* iproute2 v.5.0.0-2.0
* OpenWRT 19.07 with kernel 4.14.131 armv7l

The mv88e6060 driver is very simple. It has no support for VLANs. It
does not even have support for offloading bridging between ports to
the switch.

The data sheet for this device is open. So if you want to hack on the
driver, you could do.

	Andrew

Are you sure? That is a bit confusing after reading
https://lore.kernel.org/patchwork/patch/575746/

Quoting that patch:

	This commit implements the switchdev operations to add, delete
	and dump VLANs for the Marvell 88E6352 and compatible switch
	chips.

Vivien added support for the 6352. That uses the mv88e6xxx driver, not
the mv88e6060. And by compatible switches, he meant those in the 6352
family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.

	Andrew

A simple soul might infer that mv88e6xxx includes MV88E6060, at least
that happened to me apparently (being said simpleton).
That may as it be, and pardon my continued ignorance, how is it
explained then that a command as

# bridge v a dev {bridge} self vid {n} untagged pvid

reflects in

# bridge v s
a/o
# bridge mo

?

If the commands are not implemented one would expect them to fail in the
first place or not reflecting a change at all?

As stated in the initial message - kernel conf

CONFIG_NET_DSA_MV88E6060=y
CONFIG_NET_DSA_MV88E6XXX=y
CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y

Just figured that it is a  Marvell 88E6176-TFJ2. Thus that cannot be the
cause, also considering the that the commands are executing and changes
being reflected.

However, the loss of access to the node is a mystery.

Apparently the filter is doing its job as in isolating access to the
bridge if connecting though an enslaved device.
And yet the bridge is still fully accessible from other devices that or
not enslaved by that bridge. As if the filter is inverted.

The node's kernel log is showing during boot time repeated entries:

mv88e6085 f1072004.mdio-mii:10 lan{n}: configuring for phy/gmii link mode
mv88e6085 f1072004.mdio-mii:10: p3: hw VLAN 1 already used by br-{n}

Could there be a correlation with the described issue?

Is there way to debug the issue otherwise?