netdev - Re: network unstable on odroid-c1/meson8b.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Jun 2019 17:53:25 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Aymeric <mulx@...u.fr>
Cc:     netdev@...r.kernel.org, linux-amlogic@...ts.infradead.org,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Subject: Re: network unstable on odroid-c1/meson8b.

On 20.06.2019 09:55, Aymeric wrote:
> Hi,
> On 2019-06-20 00:14, Heiner Kallweit wrote:
>> On 19.06.2019 22:18, Aymeric wrote:
>>> Hello all,
>>>
> 
>> Kernel 3.10 didn't have a dedicated RTL8211F PHY driver yet, therefore
>> I assume the genphy driver was used. Do you have a line with
>> "attached PHY driver" in dmesg output of the vendor kernel?
> 
> No.
> Here is the full output of the dmesg from vendor kernel [¹].
> 
> I've also noticed something strange, it might be linked, but mac address of the board is set to a random value when using mainline kernel and I've to set it manually but not when using vendor kernel.
> 
>>
>> The dedicated PHY driver takes care of the tx delay, if the genphy
>> driver is used we have to rely on what uboot configured.
>> But if we indeed had an issue with a misconfigured delay, I think
>> the connection shouldn't be fine with just another link partner.
>> Just to have it tested you could make rtl8211f_config_init() in
>> drivers/net/phy/realtek.c a no-op (in current kernels).
>>
> 
> I'm not an expert here, just adding a "return 0;" here[²] would be enough?
> 
>> And you could compare at least the basic PHY registers 0x00 - 0x30
>> with both kernel versions, e.g. with phytool.
>>
> 
> They are not the same but I don't know what I'm looking for, so for kernel 3.10 [³] and for kernel 5.1.12 [⁴].
> 
> Aymeric
> 
> [¹]: https://paste.aplu.fr/?38ef95b44ebdbfc3#G666/YbhgU+O+tdC/2HaimUCigm8ZTB44qvQip/HJ5A=
> [²]: https://github.com/torvalds/linux/blob/241e39004581475b2802cd63c111fec43bb0123e/drivers/net/phy/realtek.c#L164
> [³]: https://paste.aplu.fr/?2dde1c32d5c68f4c#6xIa8MjTm6jpI6citEJAqFTLMMHDjFZRet/M00/EwjU=
> [⁴]: https://paste.aplu.fr/?32130e9bcb05dde7#N/xdnvb5GklcJtiOxMpTCm+9gsUliRwH8X3dcwSV+ng=
> 

The vendor kernel has some, but not really much magic:
https://github.com/hardkernel/linux/blob/odroidc-3.10.y/drivers/amlogic/ethernet/phy/am_rtl8211f.c
The write to RTL8211F_PHYCR2 is overwritten later, therefore we don't have to consider it.

The following should make the current Realtek PHY driver behave like in the vendor driver.
Could you test it?


diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index a669945eb..f300b1cc9 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -163,6 +163,10 @@ static int rtl8211f_config_init(struct phy_device *phydev)
 {
 	u16 val;
 
+	phy_write_paged(phydev, 0x0a43, 0x19, 0x0803);
+	genphy_soft_reset(phydev);
+	return 0;
+
 	/* enable TX-delay for rgmii-{id,txid}, and disable it for rgmii and
 	 * rgmii-rxid. The RX-delay can be enabled by the external RXDLY pin.
 	 */
-- 
2.22.0