netdev - Re: [PATCH net] net: phy: replace preliminary fix for PHY driver sometimes not binding to the device

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: <442e8e2a-2528-bbe8-fb74-9f998f336ad1@gmail.com>
Date:   Thu, 3 Jan 2019 21:13:38 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Norbert Jurkeit <norbert.jurkeit@....de>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Frank Crawford <frank@...wford.emu.id.au>
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.

Heiner