Re: [PATCH v2 net 2/3] net: dsa: don't advertise 'rx-vlan-filter' if VLAN filtering not global

On Tue, Mar 23, 2021 at 09:16:03AM -0700, Florian Fainelli wrote:

quoted

Would you be so kind to try this fixup patch on top?

That works for me, thank you! So for the whole patch when you resend,
you can add:

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>

Thanks again for testing!

quoted

Although I am much less confident now about submitting this as a bugfix
patch to go to stable trees. But I also kind of dislike the idea that
Tobias' patch (which returns -EOPNOTSUPP in dsa_slave_vlan_rx_add_vid)
only masks the problem and makes issues harder to reproduce.

Tobias, how bad is your problem? Do you mind if we tackle it in net-next?
Also, again, any chance you could make mv88e6xxx not refuse the 8021q
VLAN IDs?

I was thinking the same last night while sending my results, as far as I
can tell the switches that have global VLAN filtering or hellcreek are
not broken currently right?

Yes.

If only mv88e6xxx seems to be requiring special treatment, how do we
feel about adding an argument to port_vlan_add() and port_vlan_del()
that tell us the context in which they are called, that is via 802.1q
upper, or via bridge and have mv88e6xxx ignore the former but not the
latter?

How would you then describe to .port_vlan_add() those VLANs that don't
come either from the bridge nor from 8021q uppers, but from direct calls
to vlan_vid_add? A VLAN is a VLAN, and a driver with
configure_vlan_while_not_filtering should accept it.

If mv88e6xxx refuses this right away:

ip link add link lan0 name lan0.100 type vlan id 100

Then traffic through lan0.100 will be broken as soon as we do:

ip link add br0 type bridge vlan_filtering 1
ip link set lan0 master br0

So I believe we should be looking at how to make the Marvell driver
accept the VLAN, not how to help it refuse it in other ways.