netdev - Re: bug: net: dsa: mv88e6xxx: serdes Unable to communicate on fiber with vf610-zii-dev-rev-c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 19 Jul 2020 23:52:02 +0200
From:   Marek Behun <marek.behun@....cz>
To:     Chris Healy <cphealy@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev <netdev@...r.kernel.org>
Subject: Re: bug: net: dsa: mv88e6xxx: serdes Unable to communicate on fiber
 with vf610-zii-dev-rev-c

On Sun, 19 Jul 2020 14:43:49 -0700
Chris Healy <cphealy@...il.com> wrote:

> > Hmm.
> >
> > What about the errata setup?
> > It says:
> > /* The 6390 copper ports have an errata which require poking magic
> >  * values into undocumented hidden registers and then performing a
> >  * software reset.
> >  */
> > But then the port_hidden_write function is called for every port in the
> > function mv88e6390_setup_errata, not just for copper ports. Maybe Chris
> > should try to not write this hidden register for SerDes ports.  
> 
> I just disabled the mv88e6390_setup_errata all together and this did
> not result in any different behaviour on this broken fiber port.

:-( In that case I really have no idea what could be the problem.

Another thing you could try is resoldering resistors on the board so
that the switches configure themselves into NOCPU mode and the port you
are talking about configures itself into the cmode you need
(was it 1000base-x or sgmii?). Disable DSA, write yourself sysfs API
via which you can read/write switch registers by yourself. Then you can
chech if the problem on the RX path occurs. If no, read all the
registers and compare their values with the ones the mv88e6xxx driver
configures. If yes, then we know that the problem is there even if the
switch is NOCPU mode and you can inform Marvell about the bug.

Marek