netdev - Re: Unable to TX data on VSC8531

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:   Mon, 1 May 2023 13:34:11 -0700
From:   Ron Eggler <ron.eggler@...tywest.com>
To:     Horatiu Vultur <horatiu.vultur@...rochip.com>
Cc:     netdev@...r.kernel.org
Subject: Re: Unable to TX data on VSC8531

Hi Horatiu,

[snip greetings]

> I've posted here previously about the bring up of two network interfaces
> on an embedded platform that is using two the Microsemi VSC8531 PHYs.
> (previous thread: issues to bring up two VSC8531 PHYs, Thanks to Heiner
> Kallweit & Andrew Lunn).
> I'm able to seemingly fully access & operate the network interfaces
> through ifconfig (and the ip commands) and I set the ip address to match
> my /24 network. However, while it looks like I can receive & see traffic
> on the line with tcpdump, it appears like none of my frames can go out
> in TX direction and hence entries in my arp table mostly remain
> incomplete (and if there actually happens to be a complete entry,
> sending anything to it doesn't seem to work and the TX counters in
> ifconfig stay at 0. How can I further troubleshoot this? I have set the
> phy-mode to rgmii-id in the device tree and have experimented with all
> the TX_CLK delay register settings in the PHY but have failed to make
> any progress.
> Some of the VSC phys have this COMA mode, and then you need to pull
> down a GPIO to take it out of this mode. I looked a little bit but I
> didn't find anything like this for VSC8531 but maybe you can double
> check this. But in that case both the RX and TX will not work.
> Are there any errors seen in the registers 16 (0x10) or register 17
> (0x11)?
Good point rewgarding the COMA mode, I have not found anything like it. 
The RGMII connectivity should be pretty straight forward per the 
datasheet, TX0-TX4, TX_CLK, TX_CTL, RXD0-RXD4, RX_CLK & RX_CTL.
Not sure if you've seen this in the subthread that is  ongoing with 
Andrew Lunn but as part of it, I did invoke the mii-tool and got a 
pretty printout of the PHY registers, see below:

# mii-tool -vv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD, link ok
   registers for MII PHY 0:
     1040 796d 0007 0572 01e1 45e1 0005 2801
     0000 0300 4000 0000 0000 0000 0000 3000
     9000 0000 0008 0000 0000 0000 3201 1000
     0000 a020 0000 0000 802d 0021 0400 0000
   product info: vendor 00:01:c1, model 23 rev 2
   basic mode:   autonegotiation enabled
   basic status: autonegotiation complete, link ok
   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 
10baseT-FD 10baseT-HD
   advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 
10baseT-FD 10baseT-HD flow-control

Alternartively, the registers can be read with phytool also:

# phytool read eth0/0/0x10
0x9000
# phytool read eth0/0/0x11
0000

-- 
Ron