Re: mv88e6xxx broken on 6176 with "Disentangle STU from VTU"

[Tobias Waldekranz <tobias@waldekranz.com>]

On Fri, Mar 18, 2022 at 22:18, Vladimir Oltean <olteanv@gmail.com> wrote:
> Hello Tobias,
>
> On Fri, Mar 18, 2022 at 08:20:33PM +0100, Tobias Waldekranz wrote:
>> On Fri, Mar 18, 2022 at 18:28, Marek Behún <kabel@kernel.org> wrote:
>> > Hello Tobias,
>> >
>> > mv88e6xxx fails to probe in net-next on Turris Omnia, bisect leads to
>> > commit
>> >   49c98c1dc7d9 ("net: dsa: mv88e6xxx: Disentangle STU from VTU")
>> 
>> Oh wow, really sorry about that! I have it reproduced, and I understand
>> the issue.
>> 
>> > Trace:
>> >   mv88e6xxx_setup
>> >     mv88e6xxx_setup_port
>> >       mv88e6xxx_port_vlan_join(MV88E6XXX_VID_STANDALONE) OK
>> >       mv88e6xxx_port_vlan_join(MV88E6XXX_VID_BRIDGED) -EOPNOTSUPP
>> >
>> 
>> Thanks, that make it easy to find. There is a mismatch between what the
>> family-info struct says and what the chip-specific ops struct supports.
>> 
>> I'll try to send a fix ASAP.
>
> I've seen your patches, but I don't understand the problem they fix.
> For switches like 6190 indeed this is a problem. It has max_stu = 63 but
> mv88e6190_ops has no stu_getnext or stu_loadpurge. That I understand.
>
> But Marek reported the problem on 6176. There, max_sid is 0, so
> mv88e6xxx_has_stu() should already return false. Where is the
> -EOPNOTSUPP returned from?

Yeah you're right, if I remove both .max_sid and
.stu_{loadpurge,getnext} from one of the chips that I run on (6097),
everything still probes fine.

I'll keep digging.