netdev - Re: issues to bring up two VSC8531 PHYs

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]

Message-ID: <59fc6f98-0f67-f4a3-23c9-cd589aaa6af8@mistywest.com>
Date:   Thu, 13 Apr 2023 13:13:04 -0700
From:   Ron Eggler <ron.eggler@...tywest.com>
To:     Heiner Kallweit <hkallweit1@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org,
        Russell King - ARM Linux <linux@...linux.org.uk>
Subject: Re: issues to bring up two VSC8531 PHYs


On 2023-04-12 3:37 p.m., Heiner Kallweit wrote:
> On 13.04.2023 00:20, Andrew Lunn wrote:
>>>> Also, I hooked up a logic analyzer to the mdio lines and can see communications happening at boot time. Also, it appears that it's able to read the link status correctly (when a cable is plugged):
>>>> # mdio 11c20000.ethernet-ffffffff
>>>>   DEV      PHY-ID  LINK
>>>> 0x00  0x00070572  up
>>>>
>>> AFAICS there's no PHY driver yet for this model. The generic driver may or may not work.
>>> Best add a PHY driver.
>> Hi Heiner
>>
>> mscc.h:#define PHY_ID_VSC8531			  0x00070570
>>
>> mscc_main.c:
> OK, missed that. I just looked at the vitesse driver which also covers
> a number of VSCxxxx PHY's.
>
>>          .phy_id         = PHY_ID_VSC8531,
>>          .name           = "Microsemi VSC8531",
>>          .phy_id_mask    = 0xfffffff0,
>>          /* PHY_GBIT_FEATURES */
>>   
>>> Any specific reason why you set the compatible to
>>> ethernet-phy-ieee802.3-c45 for a c22 PHY?
Since the VSC8531 has a clause 45 register space, I assumed that it is a 
clause 45 PHY.
>> Ah, i missed that! The driver only uses phy_read/phy_write, not
>> phy_write_mmd() and phy_read_mmd().
>>
>> Remove the compatible string. It is not needed for C22 PHYs.

Anyways, I changed the patch specify "ethernet-phy-ieee802.3-c22" 
instead, it seems c22 is just a fallback if it's not specified per 
phy.txt - Documentation/devicetree/bindings/net/phy.txt - Linux source 
code (v4.14) - Bootlin 
<https://elixir.bootlin.com/linux/v4.14/source/Documentation/devicetree/bindings/net/phy.txt>


Okay, I tried it out, booted up and see my network interfaces:

# ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500  metric 1
         ether f6:1f:f8:73:ce:f4  txqueuelen 1000  (Ethernet)
         RX packets 0  bytes 0 (0.0 B)
         RX errors 0  dropped 0  overruns 0  frame 0
         TX packets 0  bytes 0 (0.0 B)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
         device interrupt 170

eth1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500  metric 1
         ether 7a:18:b6:23:bf:f6  txqueuelen 1000  (Ethernet)
         RX packets 0  bytes 0 (0.0 B)
         RX errors 0  dropped 0  overruns 0  frame 0
         TX packets 0  bytes 0 (0.0 B)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
         device interrupt 173

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536  metric 1
         inet 127.0.0.1  netmask 255.0.0.0
         loop  txqueuelen 1000  (Local Loopback)
         RX packets 0  bytes 0 (0.0 B)
         RX errors 0  dropped 0  overruns 0  frame 0
         TX packets 0  bytes 0 (0.0 B)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I'm pumped!

This is a huge step forward, Thank you Heiner & Andrew!

I've set IPs manually (haven't dealt with DHCP yet) but am not able to 
transfer any data yet.
(tried pinging hosts in local network). Also IP doesn't appear to be 
visible on network. Pinging localhost or own IP works fine.

I connected it with a patch cable to a laptop and fired up tcpdump on 
the laptop.
I can see ARP requests going out (from the laptop) but VSC8531s are not 
responding (tried both ports).
What else can I do from here, is it time to probe the RGMII signals on 
the board?


Thanks!

-- 

Ron