[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220318201825.azuoawgdl7guafrp@skbuf>
Date: Fri, 18 Mar 2022 22:18:25 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Tobias Waldekranz <tobias@...dekranz.com>
Cc: Marek BehĂșn <kabel@...nel.org>,
Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: mv88e6xxx broken on 6176 with "Disentangle STU from VTU"
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@...nel.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?
Powered by blists - more mailing lists