linux-kernel - Delay control implemented for Marvell 88E6352/1 also works for Marvell 88E6320

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>] [day] [month] [year] [list]

Message-ID: <c6f88eab-79e0-0842-c0d3-28fc6c69a14f@elektron.elka.pw.edu.pl>
Date:   Tue, 30 Oct 2018 20:52:38 +0100
From:   "wzabolot@...ktron.elka.pw.edu.pl" <wzabolot@...ktron.elka.pw.edu.pl>
To:     LKML <linux-kernel@...r.kernel.org>
Subject: Delay control implemented for Marvell 88E6352/1 also works for
 Marvell 88E6320

Hi,

I have faced a problem with communication via Ethernet switch Marvell
88E6320
connected to the Xilinx ZynqMP chip via RGMII interface.
The whole problem and its resolution is described here:
https://forums.xilinx.com/t5/Embedded-Linux/Problem-with-Marvell-88E6320-connected-to-GEM3-in-ZynqMP/m-p/904302/highlight/false#M29845
The solution simply applies to 88E6320 chip the method to control the RGMII
lines delays implemented for 88E6352/1 chips.
Please note, that as documentation for 88E6320 is not available,
the whole solution is based just on code analysis and experiments.

The solution was successfully tested on Petalinux 2017.4, that uses
the 4.9 Linux kernel.

After resolving that problem I have investigated the newest kernel, and
found
that it still lacks the delay control for 88E6320 (of course my patch
for 4.9
is useless here as the whole implementation is completely different).
The definition of mv88e6320_ops structure in
https://elixir.bootlin.com/linux/latest/source/drivers/net/dsa/mv88e6xxx/chip.c#L3420
does not set the .port_set_rgmii_delay field.
Basing on my experiments, and review of the code, it seems that adding the

.port_set_rgmii_delay = mv88e6320_port_set_rgmii_delay,

line in the definition of that structure should switch on the RGMII
delay control
for 88E6320.
The appropriate delay control function should be defined as follows:

int mv88e6320_port_set_rgmii_delay(struct mv88e6xxx_chip *chip, int port,
                   phy_interface_t mode)
{
    if ((port < 5) && (port != 2))
        return -EOPNOTSUPP;

    return mv88e6xxx_port_set_rgmii_delay(chip, port, mode);
}

That ensures correct communication with the switch in boards where the
necessary
delays are not provided by the MAC or careful adjustment of PCB track
lengths.

Unfortunately, I can't run the newest kernel on my hardware to verify
that the
proposed solution really works.

With best regards,
Wojtek

-- 
Wojciech M Zabolotny, PhD
Institute of Electronic Systems
Faculty of Electronics and Information Technology
Warsaw University of Technology