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:   Sat, 23 Feb 2019 15:55:46 -0800
From:   Florian Fainelli <>
To:     Heiner Kallweit <>,
        Andrew Lunn <>
Cc:     Russell King - ARM Linux admin <>,
        "" <>
Subject: Re: No traffic with Marvell switch and latest linux-next

Le 2/23/19 à 1:48 PM, Heiner Kallweit a écrit :
> 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")

This is the same issue that Michal reported here:

> 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


Powered by blists - more mailing lists