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]

Date:   Sat, 29 Dec 2018 16:31:22 +0100
From:   Norbert Jurkeit <norbert.jurkeit@....de>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        "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

Am 29.12.18 um 14:55 schrieb Heiner Kallweit:
> Great, then let's go for one more test. Could you apply the following to 4.19 and start in a fail scenario?
> I would be interested in the additional dmesg line, just grep for "hk:".
>
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index 99bc3de90..20457c4e6 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -7048,6 +7048,7 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>   	new_bus->name = "r8169";
>   	new_bus->priv = tp;
>   	new_bus->parent = &pdev->dev;
> +	new_bus->phy_mask = GENMASK(31, 1);
>   	new_bus->irq[0] = PHY_IGNORE_INTERRUPT;
>   	snprintf(new_bus->id, MII_BUS_ID_SIZE, "r8169-%x",
>   		 PCI_DEVID(pdev->bus->number, pdev->devfn));
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 51990002d..b92699397 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -793,6 +793,8 @@ struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45)
>   	if (r)
>   		return ERR_PTR(r);
>   
> +	pr_info("hk: addr = %d, phyid = 0x%08x, bmcr = 0x%x\n", addr, phy_id, mdiobus_read(bus, addr, 0));
> +
>   	/* If the phy_id is mostly Fs, there is no device there */
>   	if ((phy_id & 0x1fffffff) == 0x1fffffff)
>   		return ERR_PTR(-ENODEV);

Damn. I applied the patch to mainline kernel 4.19.10 because most object 
files already exist and this kernel is known to fail without patches. 
Although not intended the above patch makes it work, i.e. the link comes 
up at the end of the boot process. FWIW, the dmesg lines are:

[    2.164120] libphy: hk: addr = 0, phyid = 0xffffffff, bmcr = 0xffff
[    2.164122] libphy: hk: addr = 1, phyid = 0xffffffff, bmcr = 0xffff
[    2.164123] libphy: hk: addr = 2, phyid = 0xffffffff, bmcr = 0xffff
[    2.164123] libphy: hk: addr = 3, phyid = 0xffffffff, bmcr = 0xffff
[    2.164124] libphy: hk: addr = 4, phyid = 0xffffffff, bmcr = 0xffff
[    2.164125] libphy: hk: addr = 5, phyid = 0xffffffff, bmcr = 0xffff
[    2.164126] libphy: hk: addr = 6, phyid = 0xffffffff, bmcr = 0xffff
[    2.164127] libphy: hk: addr = 7, phyid = 0xffffffff, bmcr = 0xffff
[    2.164128] libphy: hk: addr = 8, phyid = 0xffffffff, bmcr = 0xffff
[    2.164129] libphy: hk: addr = 9, phyid = 0xffffffff, bmcr = 0xffff
[    2.164130] libphy: hk: addr = 10, phyid = 0xffffffff, bmcr = 0xffff
[    2.164130] libphy: hk: addr = 11, phyid = 0xffffffff, bmcr = 0xffff
[    2.164131] libphy: hk: addr = 12, phyid = 0xffffffff, bmcr = 0xffff
[    2.164132] libphy: hk: addr = 13, phyid = 0xffffffff, bmcr = 0xffff
[    2.164133] libphy: hk: addr = 14, phyid = 0xffffffff, bmcr = 0xffff
[    2.164134] libphy: hk: addr = 15, phyid = 0xffffffff, bmcr = 0xffff
[    2.164135] libphy: hk: addr = 16, phyid = 0xffffffff, bmcr = 0xffff
[    2.164136] libphy: hk: addr = 17, phyid = 0xffffffff, bmcr = 0xffff
[    2.164136] libphy: hk: addr = 18, phyid = 0xffffffff, bmcr = 0xffff
[    2.164137] libphy: hk: addr = 19, phyid = 0xffffffff, bmcr = 0xffff
[    2.164138] libphy: hk: addr = 20, phyid = 0xffffffff, bmcr = 0xffff
[    2.164139] libphy: hk: addr = 21, phyid = 0xffffffff, bmcr = 0xffff
[    2.164140] libphy: hk: addr = 22, phyid = 0xffffffff, bmcr = 0xffff
[    2.164141] libphy: hk: addr = 23, phyid = 0xffffffff, bmcr = 0xffff
[    2.164142] libphy: hk: addr = 24, phyid = 0xffffffff, bmcr = 0xffff
[    2.164142] libphy: hk: addr = 25, phyid = 0xffffffff, bmcr = 0xffff
[    2.164143] libphy: hk: addr = 26, phyid = 0xffffffff, bmcr = 0xffff
[    2.164144] libphy: hk: addr = 27, phyid = 0xffffffff, bmcr = 0xffff
[    2.164145] libphy: hk: addr = 28, phyid = 0xffffffff, bmcr = 0xffff
[    2.164146] libphy: hk: addr = 29, phyid = 0xffffffff, bmcr = 0xffff
[    2.164147] libphy: hk: addr = 30, phyid = 0xffffffff, bmcr = 0xffff
[    2.164148] libphy: hk: addr = 31, phyid = 0xffffffff, bmcr = 0xffff
[    4.674485] libphy: hk: addr = 0, phyid = 0x001cc912, bmcr = 0x800
[    4.682743] libphy: hk: addr = 0, phyid = 0x001cc913, bmcr = 0x1000

Please remember that my PC has also a 2. NIC of type RTL8169 which works 
fine.

I will try again with newly released kernel 4.19.13, but this will take 
longer and I can't promise better results.