netdev - Re: No traffic with Marvell switch and latest linux-next

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: <188fcef7-81fe-cffc-af71-1f37725b8611@gmail.com>
Date:   Sat, 23 Feb 2019 22:48:19 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Florian Fainelli <f.fainelli@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: No traffic with Marvell switch and latest linux-next

On 18.02.2019 19:21, Andrew Lunn wrote:
>>> Hi Heiner
>>>
>>> Watch out for boot vs reboot, and when rebooting if port 8 had link or
>>> not before you reboot.
>>>
>> Will do. Is there some known issue or bug?
> 
> Hi Heiner
> 
> No, but it is a variable which can make a difference. The fix i made
> for the Freescale GPIO controller was not an issue for cold boot, but
> reboot with link up did cause interrupt problems, etc.
> 
Hi Andrew,

it took me quite some time to debug this issue ..

At first a bisect pointed to one of my commits:
5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")

Further digging lead me to some suspicious dsa code:
In dsa_port_fixed_link_register_of() there's a call to genphy_read_status().
At the time of the call phydev->advertising is empty, therefore the fixed phy
settings are overwritten with defaults (10/half) what breaks the system.

Worth to be mentioned is that for the PHY these two flags are set:
- is_pseudo_fixed_link (that's ok)
- autoneg -> I'm not sure this is correct.

It seems that you once added the code in question:
39b0c705195e ("net: dsa: Allow configuration of CPU & DSA port speeds/duplex")

I did what I like to do most and removed some code.
W/o the calls to genphy_config_init() and genphy_read_status() it works again.
Do these calls have some purpose here with a fixed link?

My commit exposed the issue because before it genphy_read_status() read the
advertisement from chip registers instead of using phydev->advertising.

Very close to this function is dsa_port_setup_phy_of() which uses genphy_resume()
and genphy_read_status() and also looks somewhat suspicious. This code makes
quite some assumptions:
- PHY is a C22 PHY
- PHY is compatible with the generic PHY driver

>        Andrew
> 
Heiner