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

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?