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:   Thu, 3 Jan 2019 21:13:38 +0100
From:   Heiner Kallweit <>
To:     Norbert Jurkeit <>,
        Florian Fainelli <>
Cc:     Andrew Lunn <>, David Miller <>,
        "" <>,
        Frank Crawford <>
Subject: Re: [PATCH net] net: phy: replace preliminary fix for PHY driver
 sometimes not binding to the device

On 29.12.2018 12:46, Norbert Jurkeit wrote:
> Am 29.12.18 um 03:48 schrieb Florian Fainelli:
>> Heiner; are you positive that the PHY is not in a power down mode
>> (BMCR.PDOWN = 1) at the time the r8169 probe is done? Because if that
>> was the case, there is no guarantee (per 802.3 clause 22 spec) that the
>> PHY must correctly respond to MDIO operations other than read/write to
>> BMCR register and this could explain that problem, as well as the
>> general lack of connectivity for these users.
> This is a good point, at least in my case. My RTL8111 interface is connected to a Wifi router which is normally located out of sight when I sit in front of my PC, otherwise I might have noticed this earlier:
> When I reboot from kernel 4.18.18 the LAN port status LED turns off at the end of the shutdown sequence and remains off with most 4.19.* kernels until "rmmod r8169; modprobe r8169" is issued.
> When I shutdown&poweroff from kernel 4.18.18 the LED of course also turns off but lights up immediately after the PC power button is pressed. The network then comes up successfully with all tested 4.19.* kernels.
> When I reboot from kernel 4.19.* the LED does NOT turn off during shutdown (only for about 1s during boot shortly before the login screen appears) and the network also comes up successfully with all 4.19.* kernels.
I'd like to come back to these observations. I had a few German beers
to relax my mind and get fresh ideas. And it helped ..

IMO the following explains why the LED stays off when booting from 4.18
to 4.19: phylib support was added to r8169 with 4.19. Up to 4.18 the
driver had its own implementation for powering down and up the PHY.
When powering down the PHY it disabled autonegotiation. From 4.19
genphy_resume() is used to power up the PHY and this function doesn't
touch the "aneg enabled" bit in the PHY (register BMCR).
Therefore aneg is disabled during boot and the LED stays off.
genphy_config_aneg() sets the "aneg enabled" bit later.

A cold boot initializes the PHY and enables aneg.

Rebooting from 4.19 doesn't disable aneg, therefore LED stays on.

I think this effect and the other issue (falsely loading genphy driver)
are overlapping and most likely not related (even if certain symptoms
seem to indicate this). At least I have no explanation for how
disabled aneg could prevent the dedicated PHY driver from binding to
the PHY device.


Powered by blists - more mailing lists