On 30/06/2019 01:23, vto...@gmail.com wrote: > On 30/06/2019 01:11, Andrew Lunn wrote: >> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vto...@googlemail.com wrote: >>> On 30/06/2019 00:49, Andrew Lunn wrote: >>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vto...@googlemail.com wrote: >>>>> * 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
