* NET: r8168/r8169 identifying fix
@ 2020-04-13 10:30 Lauri Jakku
2020-04-13 10:58 ` Leon Romanovsky
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-13 10:30 UTC (permalink / raw)
To: netdev, Heiner Kallweit, nic_swsd
[-- Attachment #1: Type: text/plain, Size: 6110 bytes --]
From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Mon, 13 Apr 2020 13:18:35 +0300
Subject: [PATCH] NET: r8168/r8169 identifying fix
The driver installation determination made properly by
checking PHY vs DRIVER id's.
---
drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
drivers/net/phy/mdio_bus.c | 11 +++-
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..1ea6f121b561 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
{
struct pci_dev *pdev = tp->pci_dev;
struct mii_bus *new_bus;
+ u32 phydev_id = 0;
+ u32 phydrv_id = 0;
+ u32 phydrv_id_mask = 0;
int ret;
new_bus = devm_mdiobus_alloc(&pdev->dev);
@@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
new_bus->write = r8169_mdio_write_reg;
ret = mdiobus_register(new_bus);
+ dev_info(&pdev->dev,
+ "mdiobus_register: %s, %d\n",
+ new_bus->id, ret);
if (ret)
return ret;
tp->phydev = mdiobus_get_phy(new_bus, 0);
+
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ /* tp -> phydev ok */
+ int everything_OK = 0;
+
+ /* Check driver id versus phy */
+
+ if (tp->phydev->drv) {
+ u32 phydev_masked = 0xBEEFDEAD;
+ u32 drv_masked = ~0;
+ u32 phydev_match = ~0;
+ u32 drv_match = 0xDEADBEEF;
+
+ phydev_id = tp->phydev->phy_id;
+ phydrv_id = tp->phydev->drv->phy_id;
+ phydrv_id_mask = tp->phydev->drv->phy_id_mask;
+
+ drv_masked = phydrv_id & phydrv_id_mask;
+ phydev_masked = phydev_id & phydrv_id_mask;
+
+ dev_debug(&pdev->dev,
+ "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
+ new_bus->id, phydev_id, phydev_masked,
+ phydrv_id, drv_masked);
+
+ phydev_match = phydev_masked & drv_masked;
+ phydev_match = phydev_match == phydev_masked;
+
+ drv_match = phydev_masked & drv_masked;
+ drv_match = drv_match == drv_masked;
+
+ dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
+ new_bus->id, phydev_match, drv_match);
+
+ everything_OK = (phydev_match == drv_match);
+ }
+
+ if (!everything_OK) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver
+ * is loaded.
+ */
+ dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
@@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
+ dev_dbg(&pdev->dev, "init: MAC\n");
rtl_init_mac_address(tp);
dev->ethtool_ops = &rtl8169_ethtool_ops;
@@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->hw_features |= NETIF_F_RXFCS;
jumbo_max = rtl_jumbo_max(tp);
+ dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
if (jumbo_max)
dev->max_mtu = jumbo_max;
+ dev_dbg(&pdev->dev, "init: irq mask\n");
rtl_set_irq_mask(tp);
tp->fw_name = rtl_chip_infos[chipset].fw_name;
+ dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
&tp->counters_phys_addr,
@@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!tp->counters)
return -ENOMEM;
+ dev_dbg(&pdev->dev, "init: set driver data\n");
pci_set_drvdata(pdev, dev);
+ dev_dbg(&pdev->dev, "init: register mdio\n");
rc = r8169_mdio_register(tp);
+ dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
if (rc)
return rc;
/* chip gets powered up in rtl_open() */
+ dev_dbg(&pdev->dev, "init: pll pwr down\n");
rtl_pll_power_down(tp);
rc = register_netdev(dev);
+ dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
if (rc)
goto err_mdio_unregister;
@@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (pci_dev_run_wake(pdev))
pm_runtime_put_sync(&pdev->dev);
+ dev_dbg(&pdev->dev, "init: ALL DONE!\n");
+
return 0;
err_mdio_unregister:
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 522760c8bca6..719ea48164f6 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
{
struct mdio_device *mdiodev = bus->mdio_map[addr];
+ struct phy_device *rv = NULL;
+
+ pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
if (!mdiodev)
return NULL;
@@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
return NULL;
- return container_of(mdiodev, struct phy_device, mdio);
+ rv = container_of(mdiodev, struct phy_device, mdio);
+ pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
+ bus->id, addr, mdiodev, rv);
+ return rv;
}
EXPORT_SYMBOL(mdiobus_get_phy);
@@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
bus->state = MDIOBUS_REGISTERED;
- pr_info("%s: probed\n", bus->name);
+ pr_info("%s: probed (mdiobus_register)\n", bus->name);
return 0;
error:
+ pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
while (--i >= 0) {
mdiodev = bus->mdio_map[i];
if (!mdiodev)
--
2.26.0
[-- Attachment #2: NET-r8169-module-enchansments.patch --]
[-- Type: text/x-patch, Size: 6109 bytes --]
From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Mon, 13 Apr 2020 13:18:35 +0300
Subject: [PATCH] NET: r8168/r8169 identifying fix
The driver installation determination made properly by
checking PHY vs DRIVER id's.
---
drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
drivers/net/phy/mdio_bus.c | 11 +++-
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..1ea6f121b561 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
{
struct pci_dev *pdev = tp->pci_dev;
struct mii_bus *new_bus;
+ u32 phydev_id = 0;
+ u32 phydrv_id = 0;
+ u32 phydrv_id_mask = 0;
int ret;
new_bus = devm_mdiobus_alloc(&pdev->dev);
@@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
new_bus->write = r8169_mdio_write_reg;
ret = mdiobus_register(new_bus);
+ dev_info(&pdev->dev,
+ "mdiobus_register: %s, %d\n",
+ new_bus->id, ret);
if (ret)
return ret;
tp->phydev = mdiobus_get_phy(new_bus, 0);
+
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ /* tp -> phydev ok */
+ int everything_OK = 0;
+
+ /* Check driver id versus phy */
+
+ if (tp->phydev->drv) {
+ u32 phydev_masked = 0xBEEFDEAD;
+ u32 drv_masked = ~0;
+ u32 phydev_match = ~0;
+ u32 drv_match = 0xDEADBEEF;
+
+ phydev_id = tp->phydev->phy_id;
+ phydrv_id = tp->phydev->drv->phy_id;
+ phydrv_id_mask = tp->phydev->drv->phy_id_mask;
+
+ drv_masked = phydrv_id & phydrv_id_mask;
+ phydev_masked = phydev_id & phydrv_id_mask;
+
+ dev_debug(&pdev->dev,
+ "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
+ new_bus->id, phydev_id, phydev_masked,
+ phydrv_id, drv_masked);
+
+ phydev_match = phydev_masked & drv_masked;
+ phydev_match = phydev_match == phydev_masked;
+
+ drv_match = phydev_masked & drv_masked;
+ drv_match = drv_match == drv_masked;
+
+ dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
+ new_bus->id, phydev_match, drv_match);
+
+ everything_OK = (phydev_match == drv_match);
+ }
+
+ if (!everything_OK) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver
+ * is loaded.
+ */
+ dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
@@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
+ dev_dbg(&pdev->dev, "init: MAC\n");
rtl_init_mac_address(tp);
dev->ethtool_ops = &rtl8169_ethtool_ops;
@@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->hw_features |= NETIF_F_RXFCS;
jumbo_max = rtl_jumbo_max(tp);
+ dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
if (jumbo_max)
dev->max_mtu = jumbo_max;
+ dev_dbg(&pdev->dev, "init: irq mask\n");
rtl_set_irq_mask(tp);
tp->fw_name = rtl_chip_infos[chipset].fw_name;
+ dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
&tp->counters_phys_addr,
@@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!tp->counters)
return -ENOMEM;
+ dev_dbg(&pdev->dev, "init: set driver data\n");
pci_set_drvdata(pdev, dev);
+ dev_dbg(&pdev->dev, "init: register mdio\n");
rc = r8169_mdio_register(tp);
+ dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
if (rc)
return rc;
/* chip gets powered up in rtl_open() */
+ dev_dbg(&pdev->dev, "init: pll pwr down\n");
rtl_pll_power_down(tp);
rc = register_netdev(dev);
+ dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
if (rc)
goto err_mdio_unregister;
@@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (pci_dev_run_wake(pdev))
pm_runtime_put_sync(&pdev->dev);
+ dev_dbg(&pdev->dev, "init: ALL DONE!\n");
+
return 0;
err_mdio_unregister:
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 522760c8bca6..719ea48164f6 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
{
struct mdio_device *mdiodev = bus->mdio_map[addr];
+ struct phy_device *rv = NULL;
+
+ pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
if (!mdiodev)
return NULL;
@@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
return NULL;
- return container_of(mdiodev, struct phy_device, mdio);
+ rv = container_of(mdiodev, struct phy_device, mdio);
+ pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
+ bus->id, addr, mdiodev, rv);
+ return rv;
}
EXPORT_SYMBOL(mdiobus_get_phy);
@@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
bus->state = MDIOBUS_REGISTERED;
- pr_info("%s: probed\n", bus->name);
+ pr_info("%s: probed (mdiobus_register)\n", bus->name);
return 0;
error:
+ pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
while (--i >= 0) {
mdiodev = bus->mdio_map[i];
if (!mdiodev)
--
2.26.0
^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 10:30 NET: r8168/r8169 identifying fix Lauri Jakku
@ 2020-04-13 10:58 ` Leon Romanovsky
2020-04-13 11:02 ` Lauri Jakku
2020-04-13 11:06 ` Lauri Jakku
0 siblings, 2 replies; 57+ messages in thread
From: Leon Romanovsky @ 2020-04-13 10:58 UTC (permalink / raw)
To: Lauri Jakku; +Cc: netdev, Heiner Kallweit, nic_swsd
On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
> From: Lauri Jakku <lja@iki.fi>
> Date: Mon, 13 Apr 2020 13:18:35 +0300
> Subject: [PATCH] NET: r8168/r8169 identifying fix
>
> The driver installation determination made properly by
> checking PHY vs DRIVER id's.
> ---
> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
> drivers/net/phy/mdio_bus.c | 11 +++-
> 2 files changed, 72 insertions(+), 9 deletions(-)
I would say that most of the code is debug prints.
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index bf5bf05970a2..1ea6f121b561 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> {
> struct pci_dev *pdev = tp->pci_dev;
> struct mii_bus *new_bus;
> + u32 phydev_id = 0;
> + u32 phydrv_id = 0;
> + u32 phydrv_id_mask = 0;
> int ret;
>
> new_bus = devm_mdiobus_alloc(&pdev->dev);
> @@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> new_bus->write = r8169_mdio_write_reg;
>
> ret = mdiobus_register(new_bus);
> + dev_info(&pdev->dev,
> + "mdiobus_register: %s, %d\n",
> + new_bus->id, ret);
> if (ret)
> return ret;
>
> tp->phydev = mdiobus_get_phy(new_bus, 0);
> +
> if (!tp->phydev) {
> mdiobus_unregister(new_bus);
> return -ENODEV;
> - } else if (!tp->phydev->drv) {
> - /* Most chip versions fail with the genphy driver.
> - * Therefore ensure that the dedicated PHY driver is loaded.
> - */
> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> - mdiobus_unregister(new_bus);
> - return -EUNATCH;
> + } else {
> + /* tp -> phydev ok */
> + int everything_OK = 0;
> +
> + /* Check driver id versus phy */
> +
> + if (tp->phydev->drv) {
> + u32 phydev_masked = 0xBEEFDEAD;
> + u32 drv_masked = ~0;
> + u32 phydev_match = ~0;
> + u32 drv_match = 0xDEADBEEF;
> +
> + phydev_id = tp->phydev->phy_id;
> + phydrv_id = tp->phydev->drv->phy_id;
> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
> +
> + drv_masked = phydrv_id & phydrv_id_mask;
> + phydev_masked = phydev_id & phydrv_id_mask;
Please don't do vertical space alignment, every change later near such
lines will be whitespace disaster.
Thanks
> +
> + dev_debug(&pdev->dev,
> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
> + new_bus->id, phydev_id, phydev_masked,
> + phydrv_id, drv_masked);
> +
> + phydev_match = phydev_masked & drv_masked;
> + phydev_match = phydev_match == phydev_masked;
> +
> + drv_match = phydev_masked & drv_masked;
> + drv_match = drv_match == drv_masked;
> +
> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
> + new_bus->id, phydev_match, drv_match);
> +
> + everything_OK = (phydev_match == drv_match);
> + }
> +
> + if (!everything_OK) {
> + /* Most chip versions fail with the genphy driver.
> + * Therefore ensure that the dedicated PHY driver
> + * is loaded.
> + */
> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> + mdiobus_unregister(new_bus);
> + return -EUNATCH;
> + }
> }
>
> /* PHY will be woken up in rtl_open() */
> @@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> u64_stats_init(&tp->rx_stats.syncp);
> u64_stats_init(&tp->tx_stats.syncp);
>
> + dev_dbg(&pdev->dev, "init: MAC\n");
> rtl_init_mac_address(tp);
>
> dev->ethtool_ops = &rtl8169_ethtool_ops;
> @@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> dev->hw_features |= NETIF_F_RXFCS;
>
> jumbo_max = rtl_jumbo_max(tp);
> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
> if (jumbo_max)
> dev->max_mtu = jumbo_max;
>
> + dev_dbg(&pdev->dev, "init: irq mask\n");
> rtl_set_irq_mask(tp);
>
> tp->fw_name = rtl_chip_infos[chipset].fw_name;
> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>
> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
> &tp->counters_phys_addr,
> @@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (!tp->counters)
> return -ENOMEM;
>
> + dev_dbg(&pdev->dev, "init: set driver data\n");
> pci_set_drvdata(pdev, dev);
>
> + dev_dbg(&pdev->dev, "init: register mdio\n");
> rc = r8169_mdio_register(tp);
> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
> if (rc)
> return rc;
>
> /* chip gets powered up in rtl_open() */
> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
> rtl_pll_power_down(tp);
>
> rc = register_netdev(dev);
> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
> if (rc)
> goto err_mdio_unregister;
>
> @@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (pci_dev_run_wake(pdev))
> pm_runtime_put_sync(&pdev->dev);
>
> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
> +
> return 0;
>
> err_mdio_unregister:
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 522760c8bca6..719ea48164f6 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
> {
> struct mdio_device *mdiodev = bus->mdio_map[addr];
> + struct phy_device *rv = NULL;
> +
> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>
> if (!mdiodev)
> return NULL;
> @@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
> return NULL;
>
> - return container_of(mdiodev, struct phy_device, mdio);
> + rv = container_of(mdiodev, struct phy_device, mdio);
> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
> + bus->id, addr, mdiodev, rv);
> + return rv;
> }
> EXPORT_SYMBOL(mdiobus_get_phy);
>
> @@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>
> bus->state = MDIOBUS_REGISTERED;
> - pr_info("%s: probed\n", bus->name);
> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
> return 0;
>
> error:
> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
> while (--i >= 0) {
> mdiodev = bus->mdio_map[i];
> if (!mdiodev)
> --
> 2.26.0
>
>
> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
> From: Lauri Jakku <lja@iki.fi>
> Date: Mon, 13 Apr 2020 13:18:35 +0300
> Subject: [PATCH] NET: r8168/r8169 identifying fix
>
> The driver installation determination made properly by
> checking PHY vs DRIVER id's.
> ---
> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
> drivers/net/phy/mdio_bus.c | 11 +++-
> 2 files changed, 72 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index bf5bf05970a2..1ea6f121b561 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> {
> struct pci_dev *pdev = tp->pci_dev;
> struct mii_bus *new_bus;
> + u32 phydev_id = 0;
> + u32 phydrv_id = 0;
> + u32 phydrv_id_mask = 0;
> int ret;
>
> new_bus = devm_mdiobus_alloc(&pdev->dev);
> @@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> new_bus->write = r8169_mdio_write_reg;
>
> ret = mdiobus_register(new_bus);
> + dev_info(&pdev->dev,
> + "mdiobus_register: %s, %d\n",
> + new_bus->id, ret);
> if (ret)
> return ret;
>
> tp->phydev = mdiobus_get_phy(new_bus, 0);
> +
> if (!tp->phydev) {
> mdiobus_unregister(new_bus);
> return -ENODEV;
> - } else if (!tp->phydev->drv) {
> - /* Most chip versions fail with the genphy driver.
> - * Therefore ensure that the dedicated PHY driver is loaded.
> - */
> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> - mdiobus_unregister(new_bus);
> - return -EUNATCH;
> + } else {
> + /* tp -> phydev ok */
> + int everything_OK = 0;
> +
> + /* Check driver id versus phy */
> +
> + if (tp->phydev->drv) {
> + u32 phydev_masked = 0xBEEFDEAD;
> + u32 drv_masked = ~0;
> + u32 phydev_match = ~0;
> + u32 drv_match = 0xDEADBEEF;
> +
> + phydev_id = tp->phydev->phy_id;
> + phydrv_id = tp->phydev->drv->phy_id;
> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
> +
> + drv_masked = phydrv_id & phydrv_id_mask;
> + phydev_masked = phydev_id & phydrv_id_mask;
> +
> + dev_debug(&pdev->dev,
> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
> + new_bus->id, phydev_id, phydev_masked,
> + phydrv_id, drv_masked);
> +
> + phydev_match = phydev_masked & drv_masked;
> + phydev_match = phydev_match == phydev_masked;
> +
> + drv_match = phydev_masked & drv_masked;
> + drv_match = drv_match == drv_masked;
> +
> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
> + new_bus->id, phydev_match, drv_match);
> +
> + everything_OK = (phydev_match == drv_match);
> + }
> +
> + if (!everything_OK) {
> + /* Most chip versions fail with the genphy driver.
> + * Therefore ensure that the dedicated PHY driver
> + * is loaded.
> + */
> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> + mdiobus_unregister(new_bus);
> + return -EUNATCH;
> + }
> }
>
> /* PHY will be woken up in rtl_open() */
> @@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> u64_stats_init(&tp->rx_stats.syncp);
> u64_stats_init(&tp->tx_stats.syncp);
>
> + dev_dbg(&pdev->dev, "init: MAC\n");
> rtl_init_mac_address(tp);
>
> dev->ethtool_ops = &rtl8169_ethtool_ops;
> @@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> dev->hw_features |= NETIF_F_RXFCS;
>
> jumbo_max = rtl_jumbo_max(tp);
> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
> if (jumbo_max)
> dev->max_mtu = jumbo_max;
>
> + dev_dbg(&pdev->dev, "init: irq mask\n");
> rtl_set_irq_mask(tp);
>
> tp->fw_name = rtl_chip_infos[chipset].fw_name;
> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>
> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
> &tp->counters_phys_addr,
> @@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (!tp->counters)
> return -ENOMEM;
>
> + dev_dbg(&pdev->dev, "init: set driver data\n");
> pci_set_drvdata(pdev, dev);
>
> + dev_dbg(&pdev->dev, "init: register mdio\n");
> rc = r8169_mdio_register(tp);
> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
> if (rc)
> return rc;
>
> /* chip gets powered up in rtl_open() */
> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
> rtl_pll_power_down(tp);
>
> rc = register_netdev(dev);
> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
> if (rc)
> goto err_mdio_unregister;
>
> @@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (pci_dev_run_wake(pdev))
> pm_runtime_put_sync(&pdev->dev);
>
> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
> +
> return 0;
>
> err_mdio_unregister:
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 522760c8bca6..719ea48164f6 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
> {
> struct mdio_device *mdiodev = bus->mdio_map[addr];
> + struct phy_device *rv = NULL;
> +
> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>
> if (!mdiodev)
> return NULL;
> @@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
> return NULL;
>
> - return container_of(mdiodev, struct phy_device, mdio);
> + rv = container_of(mdiodev, struct phy_device, mdio);
> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
> + bus->id, addr, mdiodev, rv);
> + return rv;
> }
> EXPORT_SYMBOL(mdiobus_get_phy);
>
> @@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>
> bus->state = MDIOBUS_REGISTERED;
> - pr_info("%s: probed\n", bus->name);
> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
> return 0;
>
> error:
> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
> while (--i >= 0) {
> mdiodev = bus->mdio_map[i];
> if (!mdiodev)
> --
> 2.26.0
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 10:58 ` Leon Romanovsky
@ 2020-04-13 11:02 ` Lauri Jakku
2020-04-13 11:34 ` Leon Romanovsky
2020-04-13 11:06 ` Lauri Jakku
1 sibling, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-13 11:02 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: netdev, Heiner Kallweit, nic_swsd
Hi,
Comments inline.
On 2020-04-13 13:58, Leon Romanovsky wrote:
> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>> From: Lauri Jakku <lja@iki.fi>
>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>
>> The driver installation determination made properly by
>> checking PHY vs DRIVER id's.
>> ---
>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>> drivers/net/phy/mdio_bus.c | 11 +++-
>> 2 files changed, 72 insertions(+), 9 deletions(-)
>
> I would say that most of the code is debug prints.
>
I tought that they are helpful to keep, they are using the debug calls, so
they are not visible if user does not like those.
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index bf5bf05970a2..1ea6f121b561 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> {
>> struct pci_dev *pdev = tp->pci_dev;
>> struct mii_bus *new_bus;
>> + u32 phydev_id = 0;
>> + u32 phydrv_id = 0;
>> + u32 phydrv_id_mask = 0;
>> int ret;
>>
>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>> @@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> new_bus->write = r8169_mdio_write_reg;
>>
>> ret = mdiobus_register(new_bus);
>> + dev_info(&pdev->dev,
>> + "mdiobus_register: %s, %d\n",
>> + new_bus->id, ret);
>> if (ret)
>> return ret;
>>
>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>> +
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is loaded.
>> - */
>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> - mdiobus_unregister(new_bus);
>> - return -EUNATCH;
>> + } else {
>> + /* tp -> phydev ok */
>> + int everything_OK = 0;
>> +
>> + /* Check driver id versus phy */
>> +
>> + if (tp->phydev->drv) {
>> + u32 phydev_masked = 0xBEEFDEAD;
>> + u32 drv_masked = ~0;
>> + u32 phydev_match = ~0;
>> + u32 drv_match = 0xDEADBEEF;
>> +
>> + phydev_id = tp->phydev->phy_id;
>> + phydrv_id = tp->phydev->drv->phy_id;
>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>> +
>> + drv_masked = phydrv_id & phydrv_id_mask;
>> + phydev_masked = phydev_id & phydrv_id_mask;
>
> Please don't do vertical space alignment, every change later near such
> lines will be whitespace disaster.
>
Ok, i'll reformat this.
> Thanks
>
>> +
>> + dev_debug(&pdev->dev,
>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>> + new_bus->id, phydev_id, phydev_masked,
>> + phydrv_id, drv_masked);
>> +
>> + phydev_match = phydev_masked & drv_masked;
>> + phydev_match = phydev_match == phydev_masked;
>> +
>> + drv_match = phydev_masked & drv_masked;
>> + drv_match = drv_match == drv_masked;
>> +
>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>> + new_bus->id, phydev_match, drv_match);
>> +
>> + everything_OK = (phydev_match == drv_match);
>> + }
>> +
>> + if (!everything_OK) {
>> + /* Most chip versions fail with the genphy driver.
>> + * Therefore ensure that the dedicated PHY driver
>> + * is loaded.
>> + */
>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> + mdiobus_unregister(new_bus);
>> + return -EUNATCH;
>> + }
>> }
>>
>> /* PHY will be woken up in rtl_open() */
>> @@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> u64_stats_init(&tp->rx_stats.syncp);
>> u64_stats_init(&tp->tx_stats.syncp);
>>
>> + dev_dbg(&pdev->dev, "init: MAC\n");
>> rtl_init_mac_address(tp);
>>
>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>> @@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> dev->hw_features |= NETIF_F_RXFCS;
>>
>> jumbo_max = rtl_jumbo_max(tp);
>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>> if (jumbo_max)
>> dev->max_mtu = jumbo_max;
>>
>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>> rtl_set_irq_mask(tp);
>>
>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>
>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>> &tp->counters_phys_addr,
>> @@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (!tp->counters)
>> return -ENOMEM;
>>
>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>> pci_set_drvdata(pdev, dev);
>>
>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>> rc = r8169_mdio_register(tp);
>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>> if (rc)
>> return rc;
>>
>> /* chip gets powered up in rtl_open() */
>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>> rtl_pll_power_down(tp);
>>
>> rc = register_netdev(dev);
>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>> if (rc)
>> goto err_mdio_unregister;
>>
>> @@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (pci_dev_run_wake(pdev))
>> pm_runtime_put_sync(&pdev->dev);
>>
>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>> +
>> return 0;
>>
>> err_mdio_unregister:
>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>> index 522760c8bca6..719ea48164f6 100644
>> --- a/drivers/net/phy/mdio_bus.c
>> +++ b/drivers/net/phy/mdio_bus.c
>> @@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>> {
>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>> + struct phy_device *rv = NULL;
>> +
>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>
>> if (!mdiodev)
>> return NULL;
>> @@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>> return NULL;
>>
>> - return container_of(mdiodev, struct phy_device, mdio);
>> + rv = container_of(mdiodev, struct phy_device, mdio);
>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>> + bus->id, addr, mdiodev, rv);
>> + return rv;
>> }
>> EXPORT_SYMBOL(mdiobus_get_phy);
>>
>> @@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>
>> bus->state = MDIOBUS_REGISTERED;
>> - pr_info("%s: probed\n", bus->name);
>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>> return 0;
>>
>> error:
>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>> while (--i >= 0) {
>> mdiodev = bus->mdio_map[i];
>> if (!mdiodev)
>> --
>> 2.26.0
>>
>>
>
>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>> From: Lauri Jakku <lja@iki.fi>
>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>
>> The driver installation determination made properly by
>> checking PHY vs DRIVER id's.
>> ---
>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>> drivers/net/phy/mdio_bus.c | 11 +++-
>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index bf5bf05970a2..1ea6f121b561 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> {
>> struct pci_dev *pdev = tp->pci_dev;
>> struct mii_bus *new_bus;
>> + u32 phydev_id = 0;
>> + u32 phydrv_id = 0;
>> + u32 phydrv_id_mask = 0;
>> int ret;
>>
>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>> @@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> new_bus->write = r8169_mdio_write_reg;
>>
>> ret = mdiobus_register(new_bus);
>> + dev_info(&pdev->dev,
>> + "mdiobus_register: %s, %d\n",
>> + new_bus->id, ret);
>> if (ret)
>> return ret;
>>
>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>> +
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is loaded.
>> - */
>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> - mdiobus_unregister(new_bus);
>> - return -EUNATCH;
>> + } else {
>> + /* tp -> phydev ok */
>> + int everything_OK = 0;
>> +
>> + /* Check driver id versus phy */
>> +
>> + if (tp->phydev->drv) {
>> + u32 phydev_masked = 0xBEEFDEAD;
>> + u32 drv_masked = ~0;
>> + u32 phydev_match = ~0;
>> + u32 drv_match = 0xDEADBEEF;
>> +
>> + phydev_id = tp->phydev->phy_id;
>> + phydrv_id = tp->phydev->drv->phy_id;
>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>> +
>> + drv_masked = phydrv_id & phydrv_id_mask;
>> + phydev_masked = phydev_id & phydrv_id_mask;
>> +
>> + dev_debug(&pdev->dev,
>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>> + new_bus->id, phydev_id, phydev_masked,
>> + phydrv_id, drv_masked);
>> +
>> + phydev_match = phydev_masked & drv_masked;
>> + phydev_match = phydev_match == phydev_masked;
>> +
>> + drv_match = phydev_masked & drv_masked;
>> + drv_match = drv_match == drv_masked;
>> +
>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>> + new_bus->id, phydev_match, drv_match);
>> +
>> + everything_OK = (phydev_match == drv_match);
>> + }
>> +
>> + if (!everything_OK) {
>> + /* Most chip versions fail with the genphy driver.
>> + * Therefore ensure that the dedicated PHY driver
>> + * is loaded.
>> + */
>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> + mdiobus_unregister(new_bus);
>> + return -EUNATCH;
>> + }
>> }
>>
>> /* PHY will be woken up in rtl_open() */
>> @@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> u64_stats_init(&tp->rx_stats.syncp);
>> u64_stats_init(&tp->tx_stats.syncp);
>>
>> + dev_dbg(&pdev->dev, "init: MAC\n");
>> rtl_init_mac_address(tp);
>>
>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>> @@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> dev->hw_features |= NETIF_F_RXFCS;
>>
>> jumbo_max = rtl_jumbo_max(tp);
>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>> if (jumbo_max)
>> dev->max_mtu = jumbo_max;
>>
>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>> rtl_set_irq_mask(tp);
>>
>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>
>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>> &tp->counters_phys_addr,
>> @@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (!tp->counters)
>> return -ENOMEM;
>>
>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>> pci_set_drvdata(pdev, dev);
>>
>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>> rc = r8169_mdio_register(tp);
>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>> if (rc)
>> return rc;
>>
>> /* chip gets powered up in rtl_open() */
>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>> rtl_pll_power_down(tp);
>>
>> rc = register_netdev(dev);
>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>> if (rc)
>> goto err_mdio_unregister;
>>
>> @@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (pci_dev_run_wake(pdev))
>> pm_runtime_put_sync(&pdev->dev);
>>
>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>> +
>> return 0;
>>
>> err_mdio_unregister:
>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>> index 522760c8bca6..719ea48164f6 100644
>> --- a/drivers/net/phy/mdio_bus.c
>> +++ b/drivers/net/phy/mdio_bus.c
>> @@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>> {
>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>> + struct phy_device *rv = NULL;
>> +
>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>
>> if (!mdiodev)
>> return NULL;
>> @@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>> return NULL;
>>
>> - return container_of(mdiodev, struct phy_device, mdio);
>> + rv = container_of(mdiodev, struct phy_device, mdio);
>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>> + bus->id, addr, mdiodev, rv);
>> + return rv;
>> }
>> EXPORT_SYMBOL(mdiobus_get_phy);
>>
>> @@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>
>> bus->state = MDIOBUS_REGISTERED;
>> - pr_info("%s: probed\n", bus->name);
>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>> return 0;
>>
>> error:
>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>> while (--i >= 0) {
>> mdiodev = bus->mdio_map[i];
>> if (!mdiodev)
>> --
>> 2.26.0
>>
>
Br,
Lauri Jakku
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 10:58 ` Leon Romanovsky
2020-04-13 11:02 ` Lauri Jakku
@ 2020-04-13 11:06 ` Lauri Jakku
2020-04-13 11:28 ` Heiner Kallweit
1 sibling, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-13 11:06 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: netdev, Heiner Kallweit, nic_swsd
[-- Attachment #1: Type: text/plain, Size: 19722 bytes --]
Hi,
Modified as suggested:
From f4fba16025260bf08f0df867c3de51803ddb78ef Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Mon, 13 Apr 2020 13:18:35 +0300
Subject: [PATCH] NET: r8168/r8169 identifying fix
The driver installation determination made properly by
checking PHY vs DRIVER id's.
---
drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
drivers/net/phy/mdio_bus.c | 11 +++-
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..2384da7d2988 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
{
struct pci_dev *pdev = tp->pci_dev;
struct mii_bus *new_bus;
+ u32 phydev_id = 0;
+ u32 phydrv_id = 0;
+ u32 phydrv_id_mask = 0;
int ret;
new_bus = devm_mdiobus_alloc(&pdev->dev);
@@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
new_bus->write = r8169_mdio_write_reg;
ret = mdiobus_register(new_bus);
+ dev_info(&pdev->dev,
+ "mdiobus_register: %s, %d\n",
+ new_bus->id, ret);
if (ret)
return ret;
tp->phydev = mdiobus_get_phy(new_bus, 0);
+
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ /* tp -> phydev ok */
+ int everything_OK = 0;
+
+ /* Check driver id versus phy */
+
+ if (tp->phydev->drv) {
+ u32 phydev_masked = 0xBEEFDEAD;
+ u32 drv_masked = ~0;
+ u32 phydev_match = ~0;
+ u32 drv_match = 0xDEADBEEF;
+
+ phydev_id = tp->phydev->phy_id;
+ phydrv_id = tp->phydev->drv->phy_id;
+ phydrv_id_mask = tp->phydev->drv->phy_id_mask;
+
+ drv_masked = phydrv_id & phydrv_id_mask;
+ phydev_masked = phydev_id & phydrv_id_mask;
+
+ dev_debug(&pdev->dev,
+ "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
+ new_bus->id, phydev_id, phydev_masked,
+ phydrv_id, drv_masked);
+
+ phydev_match = phydev_masked & drv_masked;
+ phydev_match = phydev_match == phydev_masked;
+
+ drv_match = phydev_masked & drv_masked;
+ drv_match = drv_match == drv_masked;
+
+ dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
+ new_bus->id, phydev_match, drv_match);
+
+ everything_OK = (phydev_match == drv_match);
+ }
+
+ if (!everything_OK) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver
+ * is loaded.
+ */
+ dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
@@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
+ dev_dbg(&pdev->dev, "init: MAC\n");
rtl_init_mac_address(tp);
dev->ethtool_ops = &rtl8169_ethtool_ops;
@@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->hw_features |= NETIF_F_RXFCS;
jumbo_max = rtl_jumbo_max(tp);
+ dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
if (jumbo_max)
dev->max_mtu = jumbo_max;
+ dev_dbg(&pdev->dev, "init: irq mask\n");
rtl_set_irq_mask(tp);
tp->fw_name = rtl_chip_infos[chipset].fw_name;
+ dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
&tp->counters_phys_addr,
@@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!tp->counters)
return -ENOMEM;
+ dev_dbg(&pdev->dev, "init: set driver data\n");
pci_set_drvdata(pdev, dev);
+ dev_dbg(&pdev->dev, "init: register mdio\n");
rc = r8169_mdio_register(tp);
+ dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
if (rc)
return rc;
/* chip gets powered up in rtl_open() */
+ dev_dbg(&pdev->dev, "init: pll pwr down\n");
rtl_pll_power_down(tp);
rc = register_netdev(dev);
+ dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
if (rc)
goto err_mdio_unregister;
@@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (pci_dev_run_wake(pdev))
pm_runtime_put_sync(&pdev->dev);
+ dev_dbg(&pdev->dev, "init: ALL DONE!\n");
+
return 0;
err_mdio_unregister:
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 522760c8bca6..719ea48164f6 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
{
struct mdio_device *mdiodev = bus->mdio_map[addr];
+ struct phy_device *rv = NULL;
+
+ pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
if (!mdiodev)
return NULL;
@@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
return NULL;
- return container_of(mdiodev, struct phy_device, mdio);
+ rv = container_of(mdiodev, struct phy_device, mdio);
+ pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
+ bus->id, addr, mdiodev, rv);
+ return rv;
}
EXPORT_SYMBOL(mdiobus_get_phy);
@@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
bus->state = MDIOBUS_REGISTERED;
- pr_info("%s: probed\n", bus->name);
+ pr_info("%s: probed (mdiobus_register)\n", bus->name);
return 0;
error:
+ pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
while (--i >= 0) {
mdiodev = bus->mdio_map[i];
if (!mdiodev)
--
2.26.0
On 2020-04-13 13:58, Leon Romanovsky wrote:
> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>> From: Lauri Jakku <lja@iki.fi>
>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>
>> The driver installation determination made properly by
>> checking PHY vs DRIVER id's.
>> ---
>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>> drivers/net/phy/mdio_bus.c | 11 +++-
>> 2 files changed, 72 insertions(+), 9 deletions(-)
>
> I would say that most of the code is debug prints.
>
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index bf5bf05970a2..1ea6f121b561 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> {
>> struct pci_dev *pdev = tp->pci_dev;
>> struct mii_bus *new_bus;
>> + u32 phydev_id = 0;
>> + u32 phydrv_id = 0;
>> + u32 phydrv_id_mask = 0;
>> int ret;
>>
>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>> @@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> new_bus->write = r8169_mdio_write_reg;
>>
>> ret = mdiobus_register(new_bus);
>> + dev_info(&pdev->dev,
>> + "mdiobus_register: %s, %d\n",
>> + new_bus->id, ret);
>> if (ret)
>> return ret;
>>
>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>> +
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is loaded.
>> - */
>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> - mdiobus_unregister(new_bus);
>> - return -EUNATCH;
>> + } else {
>> + /* tp -> phydev ok */
>> + int everything_OK = 0;
>> +
>> + /* Check driver id versus phy */
>> +
>> + if (tp->phydev->drv) {
>> + u32 phydev_masked = 0xBEEFDEAD;
>> + u32 drv_masked = ~0;
>> + u32 phydev_match = ~0;
>> + u32 drv_match = 0xDEADBEEF;
>> +
>> + phydev_id = tp->phydev->phy_id;
>> + phydrv_id = tp->phydev->drv->phy_id;
>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>> +
>> + drv_masked = phydrv_id & phydrv_id_mask;
>> + phydev_masked = phydev_id & phydrv_id_mask;
>
> Please don't do vertical space alignment, every change later near such
> lines will be whitespace disaster.
>
> Thanks
>
>> +
>> + dev_debug(&pdev->dev,
>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>> + new_bus->id, phydev_id, phydev_masked,
>> + phydrv_id, drv_masked);
>> +
>> + phydev_match = phydev_masked & drv_masked;
>> + phydev_match = phydev_match == phydev_masked;
>> +
>> + drv_match = phydev_masked & drv_masked;
>> + drv_match = drv_match == drv_masked;
>> +
>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>> + new_bus->id, phydev_match, drv_match);
>> +
>> + everything_OK = (phydev_match == drv_match);
>> + }
>> +
>> + if (!everything_OK) {
>> + /* Most chip versions fail with the genphy driver.
>> + * Therefore ensure that the dedicated PHY driver
>> + * is loaded.
>> + */
>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> + mdiobus_unregister(new_bus);
>> + return -EUNATCH;
>> + }
>> }
>>
>> /* PHY will be woken up in rtl_open() */
>> @@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> u64_stats_init(&tp->rx_stats.syncp);
>> u64_stats_init(&tp->tx_stats.syncp);
>>
>> + dev_dbg(&pdev->dev, "init: MAC\n");
>> rtl_init_mac_address(tp);
>>
>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>> @@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> dev->hw_features |= NETIF_F_RXFCS;
>>
>> jumbo_max = rtl_jumbo_max(tp);
>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>> if (jumbo_max)
>> dev->max_mtu = jumbo_max;
>>
>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>> rtl_set_irq_mask(tp);
>>
>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>
>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>> &tp->counters_phys_addr,
>> @@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (!tp->counters)
>> return -ENOMEM;
>>
>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>> pci_set_drvdata(pdev, dev);
>>
>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>> rc = r8169_mdio_register(tp);
>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>> if (rc)
>> return rc;
>>
>> /* chip gets powered up in rtl_open() */
>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>> rtl_pll_power_down(tp);
>>
>> rc = register_netdev(dev);
>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>> if (rc)
>> goto err_mdio_unregister;
>>
>> @@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (pci_dev_run_wake(pdev))
>> pm_runtime_put_sync(&pdev->dev);
>>
>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>> +
>> return 0;
>>
>> err_mdio_unregister:
>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>> index 522760c8bca6..719ea48164f6 100644
>> --- a/drivers/net/phy/mdio_bus.c
>> +++ b/drivers/net/phy/mdio_bus.c
>> @@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>> {
>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>> + struct phy_device *rv = NULL;
>> +
>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>
>> if (!mdiodev)
>> return NULL;
>> @@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>> return NULL;
>>
>> - return container_of(mdiodev, struct phy_device, mdio);
>> + rv = container_of(mdiodev, struct phy_device, mdio);
>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>> + bus->id, addr, mdiodev, rv);
>> + return rv;
>> }
>> EXPORT_SYMBOL(mdiobus_get_phy);
>>
>> @@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>
>> bus->state = MDIOBUS_REGISTERED;
>> - pr_info("%s: probed\n", bus->name);
>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>> return 0;
>>
>> error:
>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>> while (--i >= 0) {
>> mdiodev = bus->mdio_map[i];
>> if (!mdiodev)
>> --
>> 2.26.0
>>
>>
>
>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>> From: Lauri Jakku <lja@iki.fi>
>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>
>> The driver installation determination made properly by
>> checking PHY vs DRIVER id's.
>> ---
>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>> drivers/net/phy/mdio_bus.c | 11 +++-
>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index bf5bf05970a2..1ea6f121b561 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> {
>> struct pci_dev *pdev = tp->pci_dev;
>> struct mii_bus *new_bus;
>> + u32 phydev_id = 0;
>> + u32 phydrv_id = 0;
>> + u32 phydrv_id_mask = 0;
>> int ret;
>>
>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>> @@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> new_bus->write = r8169_mdio_write_reg;
>>
>> ret = mdiobus_register(new_bus);
>> + dev_info(&pdev->dev,
>> + "mdiobus_register: %s, %d\n",
>> + new_bus->id, ret);
>> if (ret)
>> return ret;
>>
>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>> +
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is loaded.
>> - */
>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> - mdiobus_unregister(new_bus);
>> - return -EUNATCH;
>> + } else {
>> + /* tp -> phydev ok */
>> + int everything_OK = 0;
>> +
>> + /* Check driver id versus phy */
>> +
>> + if (tp->phydev->drv) {
>> + u32 phydev_masked = 0xBEEFDEAD;
>> + u32 drv_masked = ~0;
>> + u32 phydev_match = ~0;
>> + u32 drv_match = 0xDEADBEEF;
>> +
>> + phydev_id = tp->phydev->phy_id;
>> + phydrv_id = tp->phydev->drv->phy_id;
>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>> +
>> + drv_masked = phydrv_id & phydrv_id_mask;
>> + phydev_masked = phydev_id & phydrv_id_mask;
>> +
>> + dev_debug(&pdev->dev,
>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>> + new_bus->id, phydev_id, phydev_masked,
>> + phydrv_id, drv_masked);
>> +
>> + phydev_match = phydev_masked & drv_masked;
>> + phydev_match = phydev_match == phydev_masked;
>> +
>> + drv_match = phydev_masked & drv_masked;
>> + drv_match = drv_match == drv_masked;
>> +
>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>> + new_bus->id, phydev_match, drv_match);
>> +
>> + everything_OK = (phydev_match == drv_match);
>> + }
>> +
>> + if (!everything_OK) {
>> + /* Most chip versions fail with the genphy driver.
>> + * Therefore ensure that the dedicated PHY driver
>> + * is loaded.
>> + */
>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> + mdiobus_unregister(new_bus);
>> + return -EUNATCH;
>> + }
>> }
>>
>> /* PHY will be woken up in rtl_open() */
>> @@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> u64_stats_init(&tp->rx_stats.syncp);
>> u64_stats_init(&tp->tx_stats.syncp);
>>
>> + dev_dbg(&pdev->dev, "init: MAC\n");
>> rtl_init_mac_address(tp);
>>
>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>> @@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> dev->hw_features |= NETIF_F_RXFCS;
>>
>> jumbo_max = rtl_jumbo_max(tp);
>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>> if (jumbo_max)
>> dev->max_mtu = jumbo_max;
>>
>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>> rtl_set_irq_mask(tp);
>>
>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>
>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>> &tp->counters_phys_addr,
>> @@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (!tp->counters)
>> return -ENOMEM;
>>
>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>> pci_set_drvdata(pdev, dev);
>>
>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>> rc = r8169_mdio_register(tp);
>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>> if (rc)
>> return rc;
>>
>> /* chip gets powered up in rtl_open() */
>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>> rtl_pll_power_down(tp);
>>
>> rc = register_netdev(dev);
>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>> if (rc)
>> goto err_mdio_unregister;
>>
>> @@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (pci_dev_run_wake(pdev))
>> pm_runtime_put_sync(&pdev->dev);
>>
>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>> +
>> return 0;
>>
>> err_mdio_unregister:
>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>> index 522760c8bca6..719ea48164f6 100644
>> --- a/drivers/net/phy/mdio_bus.c
>> +++ b/drivers/net/phy/mdio_bus.c
>> @@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>> {
>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>> + struct phy_device *rv = NULL;
>> +
>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>
>> if (!mdiodev)
>> return NULL;
>> @@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>> return NULL;
>>
>> - return container_of(mdiodev, struct phy_device, mdio);
>> + rv = container_of(mdiodev, struct phy_device, mdio);
>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>> + bus->id, addr, mdiodev, rv);
>> + return rv;
>> }
>> EXPORT_SYMBOL(mdiobus_get_phy);
>>
>> @@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>
>> bus->state = MDIOBUS_REGISTERED;
>> - pr_info("%s: probed\n", bus->name);
>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>> return 0;
>>
>> error:
>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>> while (--i >= 0) {
>> mdiodev = bus->mdio_map[i];
>> if (!mdiodev)
>> --
>> 2.26.0
>>
>
--
Br,
Lauri J.
[-- Attachment #2: NET-r8169-module-enchansments.patch --]
[-- Type: text/x-patch, Size: 6090 bytes --]
From f4fba16025260bf08f0df867c3de51803ddb78ef Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Mon, 13 Apr 2020 13:18:35 +0300
Subject: [PATCH] NET: r8168/r8169 identifying fix
The driver installation determination made properly by
checking PHY vs DRIVER id's.
---
drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
drivers/net/phy/mdio_bus.c | 11 +++-
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..2384da7d2988 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
{
struct pci_dev *pdev = tp->pci_dev;
struct mii_bus *new_bus;
+ u32 phydev_id = 0;
+ u32 phydrv_id = 0;
+ u32 phydrv_id_mask = 0;
int ret;
new_bus = devm_mdiobus_alloc(&pdev->dev);
@@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
new_bus->write = r8169_mdio_write_reg;
ret = mdiobus_register(new_bus);
+ dev_info(&pdev->dev,
+ "mdiobus_register: %s, %d\n",
+ new_bus->id, ret);
if (ret)
return ret;
tp->phydev = mdiobus_get_phy(new_bus, 0);
+
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ /* tp -> phydev ok */
+ int everything_OK = 0;
+
+ /* Check driver id versus phy */
+
+ if (tp->phydev->drv) {
+ u32 phydev_masked = 0xBEEFDEAD;
+ u32 drv_masked = ~0;
+ u32 phydev_match = ~0;
+ u32 drv_match = 0xDEADBEEF;
+
+ phydev_id = tp->phydev->phy_id;
+ phydrv_id = tp->phydev->drv->phy_id;
+ phydrv_id_mask = tp->phydev->drv->phy_id_mask;
+
+ drv_masked = phydrv_id & phydrv_id_mask;
+ phydev_masked = phydev_id & phydrv_id_mask;
+
+ dev_debug(&pdev->dev,
+ "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
+ new_bus->id, phydev_id, phydev_masked,
+ phydrv_id, drv_masked);
+
+ phydev_match = phydev_masked & drv_masked;
+ phydev_match = phydev_match == phydev_masked;
+
+ drv_match = phydev_masked & drv_masked;
+ drv_match = drv_match == drv_masked;
+
+ dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
+ new_bus->id, phydev_match, drv_match);
+
+ everything_OK = (phydev_match == drv_match);
+ }
+
+ if (!everything_OK) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver
+ * is loaded.
+ */
+ dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
@@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
+ dev_dbg(&pdev->dev, "init: MAC\n");
rtl_init_mac_address(tp);
dev->ethtool_ops = &rtl8169_ethtool_ops;
@@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->hw_features |= NETIF_F_RXFCS;
jumbo_max = rtl_jumbo_max(tp);
+ dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
if (jumbo_max)
dev->max_mtu = jumbo_max;
+ dev_dbg(&pdev->dev, "init: irq mask\n");
rtl_set_irq_mask(tp);
tp->fw_name = rtl_chip_infos[chipset].fw_name;
+ dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
&tp->counters_phys_addr,
@@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!tp->counters)
return -ENOMEM;
+ dev_dbg(&pdev->dev, "init: set driver data\n");
pci_set_drvdata(pdev, dev);
+ dev_dbg(&pdev->dev, "init: register mdio\n");
rc = r8169_mdio_register(tp);
+ dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
if (rc)
return rc;
/* chip gets powered up in rtl_open() */
+ dev_dbg(&pdev->dev, "init: pll pwr down\n");
rtl_pll_power_down(tp);
rc = register_netdev(dev);
+ dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
if (rc)
goto err_mdio_unregister;
@@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (pci_dev_run_wake(pdev))
pm_runtime_put_sync(&pdev->dev);
+ dev_dbg(&pdev->dev, "init: ALL DONE!\n");
+
return 0;
err_mdio_unregister:
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 522760c8bca6..719ea48164f6 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
{
struct mdio_device *mdiodev = bus->mdio_map[addr];
+ struct phy_device *rv = NULL;
+
+ pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
if (!mdiodev)
return NULL;
@@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
return NULL;
- return container_of(mdiodev, struct phy_device, mdio);
+ rv = container_of(mdiodev, struct phy_device, mdio);
+ pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
+ bus->id, addr, mdiodev, rv);
+ return rv;
}
EXPORT_SYMBOL(mdiobus_get_phy);
@@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
bus->state = MDIOBUS_REGISTERED;
- pr_info("%s: probed\n", bus->name);
+ pr_info("%s: probed (mdiobus_register)\n", bus->name);
return 0;
error:
+ pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
while (--i >= 0) {
mdiodev = bus->mdio_map[i];
if (!mdiodev)
--
2.26.0
^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 11:06 ` Lauri Jakku
@ 2020-04-13 11:28 ` Heiner Kallweit
2020-04-13 11:40 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Heiner Kallweit @ 2020-04-13 11:28 UTC (permalink / raw)
To: Lauri Jakku, Leon Romanovsky; +Cc: netdev, nic_swsd
On 13.04.2020 13:06, Lauri Jakku wrote:
> Hi,
>
> Modified as suggested:
>
>>From f4fba16025260bf08f0df867c3de51803ddb78ef Mon Sep 17 00:00:00 2001
> From: Lauri Jakku <lja@iki.fi>
> Date: Mon, 13 Apr 2020 13:18:35 +0300
> Subject: [PATCH] NET: r8168/r8169 identifying fix
>
> The driver installation determination made properly by
> checking PHY vs DRIVER id's.
> ---
> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
> drivers/net/phy/mdio_bus.c | 11 +++-
> 2 files changed, 72 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index bf5bf05970a2..2384da7d2988 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> {
> struct pci_dev *pdev = tp->pci_dev;
> struct mii_bus *new_bus;
> + u32 phydev_id = 0;
> + u32 phydrv_id = 0;
> + u32 phydrv_id_mask = 0;
> int ret;
>
> new_bus = devm_mdiobus_alloc(&pdev->dev);
> @@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> new_bus->write = r8169_mdio_write_reg;
>
> ret = mdiobus_register(new_bus);
> + dev_info(&pdev->dev,
> + "mdiobus_register: %s, %d\n",
> + new_bus->id, ret);
> if (ret)
> return ret;
>
> tp->phydev = mdiobus_get_phy(new_bus, 0);
> +
> if (!tp->phydev) {
> mdiobus_unregister(new_bus);
> return -ENODEV;
> - } else if (!tp->phydev->drv) {
> - /* Most chip versions fail with the genphy driver.
> - * Therefore ensure that the dedicated PHY driver is loaded.
> - */
> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> - mdiobus_unregister(new_bus);
> - return -EUNATCH;
> + } else {
> + /* tp -> phydev ok */
> + int everything_OK = 0;
> +
> + /* Check driver id versus phy */
> +
> + if (tp->phydev->drv) {
> + u32 phydev_masked = 0xBEEFDEAD;
> + u32 drv_masked = ~0;
> + u32 phydev_match = ~0;
> + u32 drv_match = 0xDEADBEEF;
> +
> + phydev_id = tp->phydev->phy_id;
> + phydrv_id = tp->phydev->drv->phy_id;
> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
> +
> + drv_masked = phydrv_id & phydrv_id_mask;
> + phydev_masked = phydev_id & phydrv_id_mask;
> +
> + dev_debug(&pdev->dev,
> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
> + new_bus->id, phydev_id, phydev_masked,
> + phydrv_id, drv_masked);
> +
> + phydev_match = phydev_masked & drv_masked;
> + phydev_match = phydev_match == phydev_masked;
> +
> + drv_match = phydev_masked & drv_masked;
> + drv_match = drv_match == drv_masked;
> +
> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
> + new_bus->id, phydev_match, drv_match);
> +
> + everything_OK = (phydev_match == drv_match);
You're doing again what phy_bus_match() did. It's unclear what this should
be good for. Also it would be helpful if you could explain what the actual
issue is you're trying to fix, incl. the commit that caused the regression.
There is one known issue in 5.4.31 with chip versions with RTL8208 PHY.
This is fixed in 5.4.32.
Apart from that having r8169 in initramfs can cause issues if realtek.ko
isn't included too. Most distro's take care by checking softdeps in their
initramfs mgmt tools. One known exception is Gentoo, as their genkernel
tool doesn't check softdeps.
> + }
> +
> + if (!everything_OK) {
> + /* Most chip versions fail with the genphy driver.
> + * Therefore ensure that the dedicated PHY driver
> + * is loaded.
> + */
> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> + mdiobus_unregister(new_bus);
> + return -EUNATCH;
> + }
> }
>
> /* PHY will be woken up in rtl_open() */
> @@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> u64_stats_init(&tp->rx_stats.syncp);
> u64_stats_init(&tp->tx_stats.syncp);
>
> + dev_dbg(&pdev->dev, "init: MAC\n");
> rtl_init_mac_address(tp);
>
> dev->ethtool_ops = &rtl8169_ethtool_ops;
> @@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> dev->hw_features |= NETIF_F_RXFCS;
>
> jumbo_max = rtl_jumbo_max(tp);
> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
> if (jumbo_max)
> dev->max_mtu = jumbo_max;
>
> + dev_dbg(&pdev->dev, "init: irq mask\n");
> rtl_set_irq_mask(tp);
>
> tp->fw_name = rtl_chip_infos[chipset].fw_name;
> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>
> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
> &tp->counters_phys_addr,
> @@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (!tp->counters)
> return -ENOMEM;
>
> + dev_dbg(&pdev->dev, "init: set driver data\n");
> pci_set_drvdata(pdev, dev);
>
> + dev_dbg(&pdev->dev, "init: register mdio\n");
> rc = r8169_mdio_register(tp);
> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
> if (rc)
> return rc;
>
> /* chip gets powered up in rtl_open() */
> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
> rtl_pll_power_down(tp);
>
> rc = register_netdev(dev);
> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
> if (rc)
> goto err_mdio_unregister;
>
> @@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (pci_dev_run_wake(pdev))
> pm_runtime_put_sync(&pdev->dev);
>
> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
> +
> return 0;
>
> err_mdio_unregister:
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 522760c8bca6..719ea48164f6 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
> {
> struct mdio_device *mdiodev = bus->mdio_map[addr];
> + struct phy_device *rv = NULL;
> +
> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>
> if (!mdiodev)
> return NULL;
> @@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
> return NULL;
>
> - return container_of(mdiodev, struct phy_device, mdio);
> + rv = container_of(mdiodev, struct phy_device, mdio);
> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
> + bus->id, addr, mdiodev, rv);
> + return rv;
> }
> EXPORT_SYMBOL(mdiobus_get_phy);
>
> @@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>
> bus->state = MDIOBUS_REGISTERED;
> - pr_info("%s: probed\n", bus->name);
> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
> return 0;
>
> error:
> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
> while (--i >= 0) {
> mdiodev = bus->mdio_map[i];
> if (!mdiodev)
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 11:02 ` Lauri Jakku
@ 2020-04-13 11:34 ` Leon Romanovsky
2020-04-13 11:46 ` Lauri Jakku
2020-04-13 12:01 ` Lauri Jakku
0 siblings, 2 replies; 57+ messages in thread
From: Leon Romanovsky @ 2020-04-13 11:34 UTC (permalink / raw)
To: Lauri Jakku; +Cc: netdev, Heiner Kallweit, nic_swsd
On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote:
> Hi,
>
> Comments inline.
>
> On 2020-04-13 13:58, Leon Romanovsky wrote:
> > On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
> >> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
> >> From: Lauri Jakku <lja@iki.fi>
> >> Date: Mon, 13 Apr 2020 13:18:35 +0300
> >> Subject: [PATCH] NET: r8168/r8169 identifying fix
> >>
> >> The driver installation determination made properly by
> >> checking PHY vs DRIVER id's.
> >> ---
> >> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
> >> drivers/net/phy/mdio_bus.c | 11 +++-
> >> 2 files changed, 72 insertions(+), 9 deletions(-)
> >
> > I would say that most of the code is debug prints.
> >
>
> I tought that they are helpful to keep, they are using the debug calls, so
> they are not visible if user does not like those.
You are missing the point of who are your users.
Users want to have working device and the code. They don't need or like
to debug their kernel.
Thanks
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 11:28 ` Heiner Kallweit
@ 2020-04-13 11:40 ` Lauri Jakku
2020-04-13 11:57 ` Heiner Kallweit
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-13 11:40 UTC (permalink / raw)
To: Heiner Kallweit, Leon Romanovsky; +Cc: netdev, nic_swsd
Hi,
What i did was fix my problem: The old way of just checking the pointer, did not work correctly. I do have
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
NIC's integrated to motherboard. Without this patch: They will not get recognised: at boot, or with rmmod/modprobe cycle, neither
works.
--> The oldway is not what has been documented sequence.
On 2020-04-13 14:28, Heiner Kallweit wrote:
> On 13.04.2020 13:06, Lauri Jakku wrote:
>> Hi,
>>
>> Modified as suggested:
>>
>> >From f4fba16025260bf08f0df867c3de51803ddb78ef Mon Sep 17 00:00:00 2001
>> From: Lauri Jakku <lja@iki.fi>
>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>
>> The driver installation determination made properly by
>> checking PHY vs DRIVER id's.
>> ---
>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>> drivers/net/phy/mdio_bus.c | 11 +++-
>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index bf5bf05970a2..2384da7d2988 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> {
>> struct pci_dev *pdev = tp->pci_dev;
>> struct mii_bus *new_bus;
>> + u32 phydev_id = 0;
>> + u32 phydrv_id = 0;
>> + u32 phydrv_id_mask = 0;
>> int ret;
>>
>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>> @@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> new_bus->write = r8169_mdio_write_reg;
>>
>> ret = mdiobus_register(new_bus);
>> + dev_info(&pdev->dev,
>> + "mdiobus_register: %s, %d\n",
>> + new_bus->id, ret);
>> if (ret)
>> return ret;
>>
>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>> +
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is loaded.
>> - */
>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> - mdiobus_unregister(new_bus);
>> - return -EUNATCH;
>> + } else {
>> + /* tp -> phydev ok */
>> + int everything_OK = 0;
>> +
>> + /* Check driver id versus phy */
>> +
>> + if (tp->phydev->drv) {
>> + u32 phydev_masked = 0xBEEFDEAD;
>> + u32 drv_masked = ~0;
>> + u32 phydev_match = ~0;
>> + u32 drv_match = 0xDEADBEEF;
>> +
>> + phydev_id = tp->phydev->phy_id;
>> + phydrv_id = tp->phydev->drv->phy_id;
>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>> +
>> + drv_masked = phydrv_id & phydrv_id_mask;
>> + phydev_masked = phydev_id & phydrv_id_mask;
>> +
>> + dev_debug(&pdev->dev,
>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>> + new_bus->id, phydev_id, phydev_masked,
>> + phydrv_id, drv_masked);
>> +
>> + phydev_match = phydev_masked & drv_masked;
>> + phydev_match = phydev_match == phydev_masked;
>> +
>> + drv_match = phydev_masked & drv_masked;
>> + drv_match = drv_match == drv_masked;
>> +
>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>> + new_bus->id, phydev_match, drv_match);
>> +
>> + everything_OK = (phydev_match == drv_match);
>
> You're doing again what phy_bus_match() did. It's unclear what this should
> be good for. Also it would be helpful if you could explain what the actual
> issue is you're trying to fix, incl. the commit that caused the regression.
> There is one known issue in 5.4.31 with chip versions with RTL8208 PHY.
> This is fixed in 5.4.32.
> Apart from that having r8169 in initramfs can cause issues if realtek.ko
> isn't included too. Most distro's take care by checking softdeps in their
> initramfs mgmt tools. One known exception is Gentoo, as their genkernel
> tool doesn't check softdeps.
>
>
>> + }
>> +
>> + if (!everything_OK) {
>> + /* Most chip versions fail with the genphy driver.
>> + * Therefore ensure that the dedicated PHY driver
>> + * is loaded.
>> + */
>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> + mdiobus_unregister(new_bus);
>> + return -EUNATCH;
>> + }
>> }
>>
>> /* PHY will be woken up in rtl_open() */
>> @@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> u64_stats_init(&tp->rx_stats.syncp);
>> u64_stats_init(&tp->tx_stats.syncp);
>>
>> + dev_dbg(&pdev->dev, "init: MAC\n");
>> rtl_init_mac_address(tp);
>>
>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>> @@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> dev->hw_features |= NETIF_F_RXFCS;
>>
>> jumbo_max = rtl_jumbo_max(tp);
>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>> if (jumbo_max)
>> dev->max_mtu = jumbo_max;
>>
>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>> rtl_set_irq_mask(tp);
>>
>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>
>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>> &tp->counters_phys_addr,
>> @@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (!tp->counters)
>> return -ENOMEM;
>>
>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>> pci_set_drvdata(pdev, dev);
>>
>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>> rc = r8169_mdio_register(tp);
>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>> if (rc)
>> return rc;
>>
>> /* chip gets powered up in rtl_open() */
>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>> rtl_pll_power_down(tp);
>>
>> rc = register_netdev(dev);
>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>> if (rc)
>> goto err_mdio_unregister;
>>
>> @@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (pci_dev_run_wake(pdev))
>> pm_runtime_put_sync(&pdev->dev);
>>
>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>> +
>> return 0;
>>
>> err_mdio_unregister:
>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>> index 522760c8bca6..719ea48164f6 100644
>> --- a/drivers/net/phy/mdio_bus.c
>> +++ b/drivers/net/phy/mdio_bus.c
>> @@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>> {
>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>> + struct phy_device *rv = NULL;
>> +
>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>
>> if (!mdiodev)
>> return NULL;
>> @@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>> return NULL;
>>
>> - return container_of(mdiodev, struct phy_device, mdio);
>> + rv = container_of(mdiodev, struct phy_device, mdio);
>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>> + bus->id, addr, mdiodev, rv);
>> + return rv;
>> }
>> EXPORT_SYMBOL(mdiobus_get_phy);
>>
>> @@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>
>> bus->state = MDIOBUS_REGISTERED;
>> - pr_info("%s: probed\n", bus->name);
>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>> return 0;
>>
>> error:
>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>> while (--i >= 0) {
>> mdiodev = bus->mdio_map[i];
>> if (!mdiodev)
>>
>
--
Br,
Lauri J.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 11:34 ` Leon Romanovsky
@ 2020-04-13 11:46 ` Lauri Jakku
[not found] ` <d3adc7f2-06bb-45bc-ab02-3d443999cefd@gmail.com>
2020-04-13 12:01 ` Lauri Jakku
1 sibling, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-13 11:46 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: netdev, Heiner Kallweit, nic_swsd
Hi,
Fair enough, i'll strip them.
-lja
On 2020-04-13 14:34, Leon Romanovsky wrote:
> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote:
>> Hi,
>>
>> Comments inline.
>>
>> On 2020-04-13 13:58, Leon Romanovsky wrote:
>>> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>>>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>>>> From: Lauri Jakku <lja@iki.fi>
>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>
>>>> The driver installation determination made properly by
>>>> checking PHY vs DRIVER id's.
>>>> ---
>>>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>>>> drivers/net/phy/mdio_bus.c | 11 +++-
>>>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>>
>>> I would say that most of the code is debug prints.
>>>
>>
>> I tought that they are helpful to keep, they are using the debug calls, so
>> they are not visible if user does not like those.
>
> You are missing the point of who are your users.
>
> Users want to have working device and the code. They don't need or like
> to debug their kernel.
>
> Thanks
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 11:40 ` Lauri Jakku
@ 2020-04-13 11:57 ` Heiner Kallweit
2020-04-13 12:04 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Heiner Kallweit @ 2020-04-13 11:57 UTC (permalink / raw)
To: Lauri Jakku; +Cc: Leon Romanovsky, netdev, nic_swsd
On 13.04.2020 13:40, Lauri Jakku wrote:
> Hi,
>
> What i did was fix my problem: The old way of just checking the pointer, did not work correctly. I do have
>
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
> 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
>
> NIC's integrated to motherboard. Without this patch: They will not get recognised: at boot, or with rmmod/modprobe cycle, neither
> works.
>
Helpful would be:
- full dmesg of last known good kernel version
- full dmesg of failing kernel version
- info whether r8169.ko and/or realtek.ko are in your initramfs
> --> The oldway is not what has been documented sequence.
>
>
>
>
> On 2020-04-13 14:28, Heiner Kallweit wrote:
>> On 13.04.2020 13:06, Lauri Jakku wrote:
>>> Hi,
>>>
>>> Modified as suggested:
>>>
>>> >From f4fba16025260bf08f0df867c3de51803ddb78ef Mon Sep 17 00:00:00 2001
>>> From: Lauri Jakku <lja@iki.fi>
>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>
>>> The driver installation determination made properly by
>>> checking PHY vs DRIVER id's.
>>> ---
>>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>>> drivers/net/phy/mdio_bus.c | 11 +++-
>>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>> index bf5bf05970a2..2384da7d2988 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>> {
>>> struct pci_dev *pdev = tp->pci_dev;
>>> struct mii_bus *new_bus;
>>> + u32 phydev_id = 0;
>>> + u32 phydrv_id = 0;
>>> + u32 phydrv_id_mask = 0;
>>> int ret;
>>>
>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>> @@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>> new_bus->write = r8169_mdio_write_reg;
>>>
>>> ret = mdiobus_register(new_bus);
>>> + dev_info(&pdev->dev,
>>> + "mdiobus_register: %s, %d\n",
>>> + new_bus->id, ret);
>>> if (ret)
>>> return ret;
>>>
>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>> +
>>> if (!tp->phydev) {
>>> mdiobus_unregister(new_bus);
>>> return -ENODEV;
>>> - } else if (!tp->phydev->drv) {
>>> - /* Most chip versions fail with the genphy driver.
>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>> - */
>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>> - mdiobus_unregister(new_bus);
>>> - return -EUNATCH;
>>> + } else {
>>> + /* tp -> phydev ok */
>>> + int everything_OK = 0;
>>> +
>>> + /* Check driver id versus phy */
>>> +
>>> + if (tp->phydev->drv) {
>>> + u32 phydev_masked = 0xBEEFDEAD;
>>> + u32 drv_masked = ~0;
>>> + u32 phydev_match = ~0;
>>> + u32 drv_match = 0xDEADBEEF;
>>> +
>>> + phydev_id = tp->phydev->phy_id;
>>> + phydrv_id = tp->phydev->drv->phy_id;
>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>> +
>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>> +
>>> + dev_debug(&pdev->dev,
>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>> + new_bus->id, phydev_id, phydev_masked,
>>> + phydrv_id, drv_masked);
>>> +
>>> + phydev_match = phydev_masked & drv_masked;
>>> + phydev_match = phydev_match == phydev_masked;
>>> +
>>> + drv_match = phydev_masked & drv_masked;
>>> + drv_match = drv_match == drv_masked;
>>> +
>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>> + new_bus->id, phydev_match, drv_match);
>>> +
>>> + everything_OK = (phydev_match == drv_match);
>>
>> You're doing again what phy_bus_match() did. It's unclear what this should
>> be good for. Also it would be helpful if you could explain what the actual
>> issue is you're trying to fix, incl. the commit that caused the regression.
>> There is one known issue in 5.4.31 with chip versions with RTL8208 PHY.
>> This is fixed in 5.4.32.
>> Apart from that having r8169 in initramfs can cause issues if realtek.ko
>> isn't included too. Most distro's take care by checking softdeps in their
>> initramfs mgmt tools. One known exception is Gentoo, as their genkernel
>> tool doesn't check softdeps.
>>
>>
>>> + }
>>> +
>>> + if (!everything_OK) {
>>> + /* Most chip versions fail with the genphy driver.
>>> + * Therefore ensure that the dedicated PHY driver
>>> + * is loaded.
>>> + */
>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>> + mdiobus_unregister(new_bus);
>>> + return -EUNATCH;
>>> + }
>>> }
>>>
>>> /* PHY will be woken up in rtl_open() */
>>> @@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> u64_stats_init(&tp->rx_stats.syncp);
>>> u64_stats_init(&tp->tx_stats.syncp);
>>>
>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>> rtl_init_mac_address(tp);
>>>
>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>> @@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> dev->hw_features |= NETIF_F_RXFCS;
>>>
>>> jumbo_max = rtl_jumbo_max(tp);
>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>> if (jumbo_max)
>>> dev->max_mtu = jumbo_max;
>>>
>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>> rtl_set_irq_mask(tp);
>>>
>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>>
>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>> &tp->counters_phys_addr,
>>> @@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> if (!tp->counters)
>>> return -ENOMEM;
>>>
>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>> pci_set_drvdata(pdev, dev);
>>>
>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>> rc = r8169_mdio_register(tp);
>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>> if (rc)
>>> return rc;
>>>
>>> /* chip gets powered up in rtl_open() */
>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>> rtl_pll_power_down(tp);
>>>
>>> rc = register_netdev(dev);
>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>> if (rc)
>>> goto err_mdio_unregister;
>>>
>>> @@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> if (pci_dev_run_wake(pdev))
>>> pm_runtime_put_sync(&pdev->dev);
>>>
>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>> +
>>> return 0;
>>>
>>> err_mdio_unregister:
>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>> index 522760c8bca6..719ea48164f6 100644
>>> --- a/drivers/net/phy/mdio_bus.c
>>> +++ b/drivers/net/phy/mdio_bus.c
>>> @@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>> {
>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>> + struct phy_device *rv = NULL;
>>> +
>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>>
>>> if (!mdiodev)
>>> return NULL;
>>> @@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>> return NULL;
>>>
>>> - return container_of(mdiodev, struct phy_device, mdio);
>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>> + bus->id, addr, mdiodev, rv);
>>> + return rv;
>>> }
>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>
>>> @@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>
>>> bus->state = MDIOBUS_REGISTERED;
>>> - pr_info("%s: probed\n", bus->name);
>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>> return 0;
>>>
>>> error:
>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>> while (--i >= 0) {
>>> mdiodev = bus->mdio_map[i];
>>> if (!mdiodev)
>>>
>>
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 11:34 ` Leon Romanovsky
2020-04-13 11:46 ` Lauri Jakku
@ 2020-04-13 12:01 ` Lauri Jakku
2020-04-13 12:18 ` Leon Romanovsky
1 sibling, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-13 12:01 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: netdev, Heiner Kallweit, nic_swsd
[-- Attachment #1: Type: text/plain, Size: 8050 bytes --]
Hi,
I've tought that the debug's are worth to save behind an definition/commented out, so they can be enabled if needed.
Latest version:
From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Mon, 13 Apr 2020 13:18:35 +0300
Subject: [PATCH] NET: r8168/r8169 identifying fix
The driver installation determination made properly by
checking PHY vs DRIVER id's.
---
drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
drivers/net/phy/mdio_bus.c | 15 ++-
2 files changed, 119 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..5e992f285527 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -61,6 +61,11 @@
#define R8169_MSG_DEFAULT \
(NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
+
+/*
+#define R8169_PROBE_DEBUG
+*/
+
/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
The RTL chips use a 64 element hash table based on the Ethernet CRC. */
#define MC_FILTER_LIMIT 32
@@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
{
struct pci_dev *pdev = tp->pci_dev;
struct mii_bus *new_bus;
+ u32 phydev_id = 0;
+ u32 phydrv_id = 0;
+ u32 phydrv_id_mask = 0;
int ret;
new_bus = devm_mdiobus_alloc(&pdev->dev);
@@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
new_bus->write = r8169_mdio_write_reg;
ret = mdiobus_register(new_bus);
+
+#ifdef R8169_PROBE_DEBUG
+ dev_info(&pdev->dev,
+ "mdiobus_register: %s, %d\n",
+ new_bus->id, ret);
+#endif
if (ret)
return ret;
tp->phydev = mdiobus_get_phy(new_bus, 0);
+
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ /* tp -> phydev ok */
+ int everything_OK = 0;
+
+ /* Check driver id versus phy */
+
+ if (tp->phydev->drv) {
+ u32 phydev_masked = 0xBEEFDEAD;
+ u32 drv_masked = ~0;
+ u32 phydev_match = ~0;
+ u32 drv_match = 0xDEADBEEF;
+
+ phydev_id = tp->phydev->phy_id;
+ phydrv_id = tp->phydev->drv->phy_id;
+ phydrv_id_mask = tp->phydev->drv->phy_id_mask;
+
+ drv_masked = phydrv_id & phydrv_id_mask;
+ phydev_masked = phydev_id & phydrv_id_mask;
+
+#ifdef R8169_PROBE_DEBUG
+ dev_debug(&pdev->dev,
+ "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
+ new_bus->id, phydev_id, phydev_masked,
+ phydrv_id, drv_masked);
+#endif
+
+ phydev_match = phydev_masked & drv_masked;
+ phydev_match = phydev_match == phydev_masked;
+
+ drv_match = phydev_masked & drv_masked;
+ drv_match = drv_match == drv_masked;
+
+#ifdef R8169_PROBE_DEBUG
+ dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
+ new_bus->id, phydev_match, drv_match);
+#endif
+
+ everything_OK = (phydev_match == drv_match);
+ }
+
+ if (!everything_OK) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver
+ * is loaded.
+ */
+ dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
@@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: MAC\n");
+#endif
+
rtl_init_mac_address(tp);
dev->ethtool_ops = &rtl8169_ethtool_ops;
@@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->hw_features |= NETIF_F_RXFCS;
jumbo_max = rtl_jumbo_max(tp);
+
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
+#endif
+
if (jumbo_max)
dev->max_mtu = jumbo_max;
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: irq mask\n");
+#endif
+
rtl_set_irq_mask(tp);
tp->fw_name = rtl_chip_infos[chipset].fw_name;
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
+#endif
+
tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
&tp->counters_phys_addr,
GFP_KERNEL);
if (!tp->counters)
return -ENOMEM;
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: set driver data\n");
+#endif
+
pci_set_drvdata(pdev, dev);
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: register mdio\n");
+#endif
+
rc = r8169_mdio_register(tp);
+
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
+#endif
+
if (rc)
return rc;
/* chip gets powered up in rtl_open() */
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: pll pwr down\n");
+#endif
+
rtl_pll_power_down(tp);
rc = register_netdev(dev);
+
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
+#endif
+
if (rc)
goto err_mdio_unregister;
@@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (pci_dev_run_wake(pdev))
pm_runtime_put_sync(&pdev->dev);
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: ALL DONE!\n");
+#endif
+
return 0;
err_mdio_unregister:
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 522760c8bca6..41777f379a57 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
{
struct mdio_device *mdiodev = bus->mdio_map[addr];
-
+ struct phy_device *rv = NULL;
+/*
+ pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
+*/
if (!mdiodev)
return NULL;
if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
return NULL;
- return container_of(mdiodev, struct phy_device, mdio);
+ rv = container_of(mdiodev, struct phy_device, mdio);
+/*
+ pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
+ bus->id, addr, mdiodev, rv);
+*/
+ return rv;
}
EXPORT_SYMBOL(mdiobus_get_phy);
@@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
bus->state = MDIOBUS_REGISTERED;
- pr_info("%s: probed\n", bus->name);
+ pr_info("%s: probed (mdiobus_register)\n", bus->name);
return 0;
error:
+ pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
while (--i >= 0) {
mdiodev = bus->mdio_map[i];
if (!mdiodev)
--
2.26.0
On 2020-04-13 14:34, Leon Romanovsky wrote:
> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote:
>> Hi,
>>
>> Comments inline.
>>
>> On 2020-04-13 13:58, Leon Romanovsky wrote:
>>> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>>>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>>>> From: Lauri Jakku <lja@iki.fi>
>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>
>>>> The driver installation determination made properly by
>>>> checking PHY vs DRIVER id's.
>>>> ---
>>>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>>>> drivers/net/phy/mdio_bus.c | 11 +++-
>>>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>>
>>> I would say that most of the code is debug prints.
>>>
>>
>> I tought that they are helpful to keep, they are using the debug calls, so
>> they are not visible if user does not like those.
>
> You are missing the point of who are your users.
>
> Users want to have working device and the code. They don't need or like
> to debug their kernel.
>
> Thanks
>
--
Br,
Lauri J.
[-- Attachment #2: NET-r8169-module-enchansments.patch --]
[-- Type: text/x-patch, Size: 6759 bytes --]
From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Mon, 13 Apr 2020 13:18:35 +0300
Subject: [PATCH] NET: r8168/r8169 identifying fix
The driver installation determination made properly by
checking PHY vs DRIVER id's.
---
drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
drivers/net/phy/mdio_bus.c | 15 ++-
2 files changed, 119 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..5e992f285527 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -61,6 +61,11 @@
#define R8169_MSG_DEFAULT \
(NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
+
+/*
+#define R8169_PROBE_DEBUG
+*/
+
/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
The RTL chips use a 64 element hash table based on the Ethernet CRC. */
#define MC_FILTER_LIMIT 32
@@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
{
struct pci_dev *pdev = tp->pci_dev;
struct mii_bus *new_bus;
+ u32 phydev_id = 0;
+ u32 phydrv_id = 0;
+ u32 phydrv_id_mask = 0;
int ret;
new_bus = devm_mdiobus_alloc(&pdev->dev);
@@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
new_bus->write = r8169_mdio_write_reg;
ret = mdiobus_register(new_bus);
+
+#ifdef R8169_PROBE_DEBUG
+ dev_info(&pdev->dev,
+ "mdiobus_register: %s, %d\n",
+ new_bus->id, ret);
+#endif
if (ret)
return ret;
tp->phydev = mdiobus_get_phy(new_bus, 0);
+
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ /* tp -> phydev ok */
+ int everything_OK = 0;
+
+ /* Check driver id versus phy */
+
+ if (tp->phydev->drv) {
+ u32 phydev_masked = 0xBEEFDEAD;
+ u32 drv_masked = ~0;
+ u32 phydev_match = ~0;
+ u32 drv_match = 0xDEADBEEF;
+
+ phydev_id = tp->phydev->phy_id;
+ phydrv_id = tp->phydev->drv->phy_id;
+ phydrv_id_mask = tp->phydev->drv->phy_id_mask;
+
+ drv_masked = phydrv_id & phydrv_id_mask;
+ phydev_masked = phydev_id & phydrv_id_mask;
+
+#ifdef R8169_PROBE_DEBUG
+ dev_debug(&pdev->dev,
+ "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
+ new_bus->id, phydev_id, phydev_masked,
+ phydrv_id, drv_masked);
+#endif
+
+ phydev_match = phydev_masked & drv_masked;
+ phydev_match = phydev_match == phydev_masked;
+
+ drv_match = phydev_masked & drv_masked;
+ drv_match = drv_match == drv_masked;
+
+#ifdef R8169_PROBE_DEBUG
+ dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
+ new_bus->id, phydev_match, drv_match);
+#endif
+
+ everything_OK = (phydev_match == drv_match);
+ }
+
+ if (!everything_OK) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver
+ * is loaded.
+ */
+ dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
@@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: MAC\n");
+#endif
+
rtl_init_mac_address(tp);
dev->ethtool_ops = &rtl8169_ethtool_ops;
@@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->hw_features |= NETIF_F_RXFCS;
jumbo_max = rtl_jumbo_max(tp);
+
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
+#endif
+
if (jumbo_max)
dev->max_mtu = jumbo_max;
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: irq mask\n");
+#endif
+
rtl_set_irq_mask(tp);
tp->fw_name = rtl_chip_infos[chipset].fw_name;
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
+#endif
+
tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
&tp->counters_phys_addr,
GFP_KERNEL);
if (!tp->counters)
return -ENOMEM;
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: set driver data\n");
+#endif
+
pci_set_drvdata(pdev, dev);
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: register mdio\n");
+#endif
+
rc = r8169_mdio_register(tp);
+
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
+#endif
+
if (rc)
return rc;
/* chip gets powered up in rtl_open() */
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: pll pwr down\n");
+#endif
+
rtl_pll_power_down(tp);
rc = register_netdev(dev);
+
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
+#endif
+
if (rc)
goto err_mdio_unregister;
@@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (pci_dev_run_wake(pdev))
pm_runtime_put_sync(&pdev->dev);
+#ifdef R816X_PROBE_DEBUG
+ dev_dbg(&pdev->dev, "init: ALL DONE!\n");
+#endif
+
return 0;
err_mdio_unregister:
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 522760c8bca6..41777f379a57 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
{
struct mdio_device *mdiodev = bus->mdio_map[addr];
-
+ struct phy_device *rv = NULL;
+/*
+ pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
+*/
if (!mdiodev)
return NULL;
if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
return NULL;
- return container_of(mdiodev, struct phy_device, mdio);
+ rv = container_of(mdiodev, struct phy_device, mdio);
+/*
+ pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
+ bus->id, addr, mdiodev, rv);
+*/
+ return rv;
}
EXPORT_SYMBOL(mdiobus_get_phy);
@@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
bus->state = MDIOBUS_REGISTERED;
- pr_info("%s: probed\n", bus->name);
+ pr_info("%s: probed (mdiobus_register)\n", bus->name);
return 0;
error:
+ pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
while (--i >= 0) {
mdiodev = bus->mdio_map[i];
if (!mdiodev)
--
2.26.0
^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 11:57 ` Heiner Kallweit
@ 2020-04-13 12:04 ` Lauri Jakku
0 siblings, 0 replies; 57+ messages in thread
From: Lauri Jakku @ 2020-04-13 12:04 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi, ok i'll provide today.. i recall that 5.3.x was ok, and from 5.4.x i found that there was not, but i'll recheck and get logs.
On 2020-04-13 14:57, Heiner Kallweit wrote:
> On 13.04.2020 13:40, Lauri Jakku wrote:
>> Hi,
>>
>> What i did was fix my problem: The old way of just checking the pointer, did not work correctly. I do have
>>
>> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
>> 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
>>
>> NIC's integrated to motherboard. Without this patch: They will not get recognised: at boot, or with rmmod/modprobe cycle, neither
>> works.
>>
> Helpful would be:
> - full dmesg of last known good kernel version
> - full dmesg of failing kernel version
> - info whether r8169.ko and/or realtek.ko are in your initramfs
>
>> --> The oldway is not what has been documented sequence.
>>
>>
>>
>>
>> On 2020-04-13 14:28, Heiner Kallweit wrote:
>>> On 13.04.2020 13:06, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> Modified as suggested:
>>>>
>>>> >From f4fba16025260bf08f0df867c3de51803ddb78ef Mon Sep 17 00:00:00 2001
>>>> From: Lauri Jakku <lja@iki.fi>
>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>
>>>> The driver installation determination made properly by
>>>> checking PHY vs DRIVER id's.
>>>> ---
>>>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>>>> drivers/net/phy/mdio_bus.c | 11 +++-
>>>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>> index bf5bf05970a2..2384da7d2988 100644
>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>> {
>>>> struct pci_dev *pdev = tp->pci_dev;
>>>> struct mii_bus *new_bus;
>>>> + u32 phydev_id = 0;
>>>> + u32 phydrv_id = 0;
>>>> + u32 phydrv_id_mask = 0;
>>>> int ret;
>>>>
>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>> @@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>> new_bus->write = r8169_mdio_write_reg;
>>>>
>>>> ret = mdiobus_register(new_bus);
>>>> + dev_info(&pdev->dev,
>>>> + "mdiobus_register: %s, %d\n",
>>>> + new_bus->id, ret);
>>>> if (ret)
>>>> return ret;
>>>>
>>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>>> +
>>>> if (!tp->phydev) {
>>>> mdiobus_unregister(new_bus);
>>>> return -ENODEV;
>>>> - } else if (!tp->phydev->drv) {
>>>> - /* Most chip versions fail with the genphy driver.
>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>> - */
>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>> - mdiobus_unregister(new_bus);
>>>> - return -EUNATCH;
>>>> + } else {
>>>> + /* tp -> phydev ok */
>>>> + int everything_OK = 0;
>>>> +
>>>> + /* Check driver id versus phy */
>>>> +
>>>> + if (tp->phydev->drv) {
>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>> + u32 drv_masked = ~0;
>>>> + u32 phydev_match = ~0;
>>>> + u32 drv_match = 0xDEADBEEF;
>>>> +
>>>> + phydev_id = tp->phydev->phy_id;
>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>> +
>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>> +
>>>> + dev_debug(&pdev->dev,
>>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>>> + new_bus->id, phydev_id, phydev_masked,
>>>> + phydrv_id, drv_masked);
>>>> +
>>>> + phydev_match = phydev_masked & drv_masked;
>>>> + phydev_match = phydev_match == phydev_masked;
>>>> +
>>>> + drv_match = phydev_masked & drv_masked;
>>>> + drv_match = drv_match == drv_masked;
>>>> +
>>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>>> + new_bus->id, phydev_match, drv_match);
>>>> +
>>>> + everything_OK = (phydev_match == drv_match);
>>>
>>> You're doing again what phy_bus_match() did. It's unclear what this should
>>> be good for. Also it would be helpful if you could explain what the actual
>>> issue is you're trying to fix, incl. the commit that caused the regression.
>>> There is one known issue in 5.4.31 with chip versions with RTL8208 PHY.
>>> This is fixed in 5.4.32.
>>> Apart from that having r8169 in initramfs can cause issues if realtek.ko
>>> isn't included too. Most distro's take care by checking softdeps in their
>>> initramfs mgmt tools. One known exception is Gentoo, as their genkernel
>>> tool doesn't check softdeps.
>>>
>>>
>>>> + }
>>>> +
>>>> + if (!everything_OK) {
>>>> + /* Most chip versions fail with the genphy driver.
>>>> + * Therefore ensure that the dedicated PHY driver
>>>> + * is loaded.
>>>> + */
>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>> + mdiobus_unregister(new_bus);
>>>> + return -EUNATCH;
>>>> + }
>>>> }
>>>>
>>>> /* PHY will be woken up in rtl_open() */
>>>> @@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> u64_stats_init(&tp->rx_stats.syncp);
>>>> u64_stats_init(&tp->tx_stats.syncp);
>>>>
>>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>>> rtl_init_mac_address(tp);
>>>>
>>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>>> @@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> dev->hw_features |= NETIF_F_RXFCS;
>>>>
>>>> jumbo_max = rtl_jumbo_max(tp);
>>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>>> if (jumbo_max)
>>>> dev->max_mtu = jumbo_max;
>>>>
>>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>>> rtl_set_irq_mask(tp);
>>>>
>>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>>>
>>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>>> &tp->counters_phys_addr,
>>>> @@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> if (!tp->counters)
>>>> return -ENOMEM;
>>>>
>>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>>> pci_set_drvdata(pdev, dev);
>>>>
>>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>>> rc = r8169_mdio_register(tp);
>>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>>> if (rc)
>>>> return rc;
>>>>
>>>> /* chip gets powered up in rtl_open() */
>>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>>> rtl_pll_power_down(tp);
>>>>
>>>> rc = register_netdev(dev);
>>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>>> if (rc)
>>>> goto err_mdio_unregister;
>>>>
>>>> @@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> if (pci_dev_run_wake(pdev))
>>>> pm_runtime_put_sync(&pdev->dev);
>>>>
>>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>>> +
>>>> return 0;
>>>>
>>>> err_mdio_unregister:
>>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>>> index 522760c8bca6..719ea48164f6 100644
>>>> --- a/drivers/net/phy/mdio_bus.c
>>>> +++ b/drivers/net/phy/mdio_bus.c
>>>> @@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>>> {
>>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>>> + struct phy_device *rv = NULL;
>>>> +
>>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>>>
>>>> if (!mdiodev)
>>>> return NULL;
>>>> @@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>>> return NULL;
>>>>
>>>> - return container_of(mdiodev, struct phy_device, mdio);
>>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>>> + bus->id, addr, mdiodev, rv);
>>>> + return rv;
>>>> }
>>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>>
>>>> @@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>>
>>>> bus->state = MDIOBUS_REGISTERED;
>>>> - pr_info("%s: probed\n", bus->name);
>>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>>> return 0;
>>>>
>>>> error:
>>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>>> while (--i >= 0) {
>>>> mdiodev = bus->mdio_map[i];
>>>> if (!mdiodev)
>>>>
>>>
>>
>
--
Br,
Lauri J.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 12:01 ` Lauri Jakku
@ 2020-04-13 12:18 ` Leon Romanovsky
2020-04-13 14:44 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Leon Romanovsky @ 2020-04-13 12:18 UTC (permalink / raw)
To: Lauri Jakku; +Cc: netdev, Heiner Kallweit, nic_swsd
On Mon, Apr 13, 2020 at 03:01:23PM +0300, Lauri Jakku wrote:
> Hi,
>
> I've tought that the debug's are worth to save behind an definition/commented out, so they can be enabled if needed.
>
Please stop to do top-posting.
>
> Latest version:
>
> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
> From: Lauri Jakku <lja@iki.fi>
> Date: Mon, 13 Apr 2020 13:18:35 +0300
> Subject: [PATCH] NET: r8168/r8169 identifying fix
>
> The driver installation determination made properly by
> checking PHY vs DRIVER id's.
> ---
> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
> drivers/net/phy/mdio_bus.c | 15 ++-
> 2 files changed, 119 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index bf5bf05970a2..5e992f285527 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -61,6 +61,11 @@
> #define R8169_MSG_DEFAULT \
> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>
> +
> +/*
> +#define R8169_PROBE_DEBUG
> +*/
Of course not, it is even worse than before.
If user recompiles module, he will add prints.
Thanks
> +
> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
> #define MC_FILTER_LIMIT 32
> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> {
> struct pci_dev *pdev = tp->pci_dev;
> struct mii_bus *new_bus;
> + u32 phydev_id = 0;
> + u32 phydrv_id = 0;
> + u32 phydrv_id_mask = 0;
> int ret;
>
> new_bus = devm_mdiobus_alloc(&pdev->dev);
> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> new_bus->write = r8169_mdio_write_reg;
>
> ret = mdiobus_register(new_bus);
> +
> +#ifdef R8169_PROBE_DEBUG
> + dev_info(&pdev->dev,
> + "mdiobus_register: %s, %d\n",
> + new_bus->id, ret);
> +#endif
> if (ret)
> return ret;
>
> tp->phydev = mdiobus_get_phy(new_bus, 0);
> +
> if (!tp->phydev) {
> mdiobus_unregister(new_bus);
> return -ENODEV;
> - } else if (!tp->phydev->drv) {
> - /* Most chip versions fail with the genphy driver.
> - * Therefore ensure that the dedicated PHY driver is loaded.
> - */
> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> - mdiobus_unregister(new_bus);
> - return -EUNATCH;
> + } else {
> + /* tp -> phydev ok */
> + int everything_OK = 0;
> +
> + /* Check driver id versus phy */
> +
> + if (tp->phydev->drv) {
> + u32 phydev_masked = 0xBEEFDEAD;
> + u32 drv_masked = ~0;
> + u32 phydev_match = ~0;
> + u32 drv_match = 0xDEADBEEF;
> +
> + phydev_id = tp->phydev->phy_id;
> + phydrv_id = tp->phydev->drv->phy_id;
> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
> +
> + drv_masked = phydrv_id & phydrv_id_mask;
> + phydev_masked = phydev_id & phydrv_id_mask;
> +
> +#ifdef R8169_PROBE_DEBUG
> + dev_debug(&pdev->dev,
> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
> + new_bus->id, phydev_id, phydev_masked,
> + phydrv_id, drv_masked);
> +#endif
> +
> + phydev_match = phydev_masked & drv_masked;
> + phydev_match = phydev_match == phydev_masked;
> +
> + drv_match = phydev_masked & drv_masked;
> + drv_match = drv_match == drv_masked;
> +
> +#ifdef R8169_PROBE_DEBUG
> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
> + new_bus->id, phydev_match, drv_match);
> +#endif
> +
> + everything_OK = (phydev_match == drv_match);
> + }
> +
> + if (!everything_OK) {
> + /* Most chip versions fail with the genphy driver.
> + * Therefore ensure that the dedicated PHY driver
> + * is loaded.
> + */
> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> + mdiobus_unregister(new_bus);
> + return -EUNATCH;
> + }
> }
>
> /* PHY will be woken up in rtl_open() */
> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> u64_stats_init(&tp->rx_stats.syncp);
> u64_stats_init(&tp->tx_stats.syncp);
>
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: MAC\n");
> +#endif
> +
> rtl_init_mac_address(tp);
>
> dev->ethtool_ops = &rtl8169_ethtool_ops;
> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> dev->hw_features |= NETIF_F_RXFCS;
>
> jumbo_max = rtl_jumbo_max(tp);
> +
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
> +#endif
> +
> if (jumbo_max)
> dev->max_mtu = jumbo_max;
>
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: irq mask\n");
> +#endif
> +
> rtl_set_irq_mask(tp);
>
> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
> +#endif
> +
> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
> &tp->counters_phys_addr,
> GFP_KERNEL);
> if (!tp->counters)
> return -ENOMEM;
>
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: set driver data\n");
> +#endif
> +
> pci_set_drvdata(pdev, dev);
>
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: register mdio\n");
> +#endif
> +
> rc = r8169_mdio_register(tp);
> +
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
> +#endif
> +
> if (rc)
> return rc;
>
> /* chip gets powered up in rtl_open() */
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
> +#endif
> +
> rtl_pll_power_down(tp);
>
> rc = register_netdev(dev);
> +
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
> +#endif
> +
> if (rc)
> goto err_mdio_unregister;
>
> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (pci_dev_run_wake(pdev))
> pm_runtime_put_sync(&pdev->dev);
>
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
> +#endif
> +
> return 0;
>
> err_mdio_unregister:
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 522760c8bca6..41777f379a57 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
> {
> struct mdio_device *mdiodev = bus->mdio_map[addr];
> -
> + struct phy_device *rv = NULL;
> +/*
> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
> +*/
> if (!mdiodev)
> return NULL;
>
> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
> return NULL;
>
> - return container_of(mdiodev, struct phy_device, mdio);
> + rv = container_of(mdiodev, struct phy_device, mdio);
> +/*
> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
> + bus->id, addr, mdiodev, rv);
> +*/
> + return rv;
> }
> EXPORT_SYMBOL(mdiobus_get_phy);
>
> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>
> bus->state = MDIOBUS_REGISTERED;
> - pr_info("%s: probed\n", bus->name);
> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
> return 0;
>
> error:
> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
> while (--i >= 0) {
> mdiodev = bus->mdio_map[i];
> if (!mdiodev)
> --
> 2.26.0
>
>
>
>
> On 2020-04-13 14:34, Leon Romanovsky wrote:
> > On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote:
> >> Hi,
> >>
> >> Comments inline.
> >>
> >> On 2020-04-13 13:58, Leon Romanovsky wrote:
> >>> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
> >>>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
> >>>> From: Lauri Jakku <lja@iki.fi>
> >>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
> >>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
> >>>>
> >>>> The driver installation determination made properly by
> >>>> checking PHY vs DRIVER id's.
> >>>> ---
> >>>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
> >>>> drivers/net/phy/mdio_bus.c | 11 +++-
> >>>> 2 files changed, 72 insertions(+), 9 deletions(-)
> >>>
> >>> I would say that most of the code is debug prints.
> >>>
> >>
> >> I tought that they are helpful to keep, they are using the debug calls, so
> >> they are not visible if user does not like those.
> >
> > You are missing the point of who are your users.
> >
> > Users want to have working device and the code. They don't need or like
> > to debug their kernel.
> >
> > Thanks
> >
>
> --
> Br,
> Lauri J.
> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
> From: Lauri Jakku <lja@iki.fi>
> Date: Mon, 13 Apr 2020 13:18:35 +0300
> Subject: [PATCH] NET: r8168/r8169 identifying fix
>
> The driver installation determination made properly by
> checking PHY vs DRIVER id's.
> ---
> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
> drivers/net/phy/mdio_bus.c | 15 ++-
> 2 files changed, 119 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index bf5bf05970a2..5e992f285527 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -61,6 +61,11 @@
> #define R8169_MSG_DEFAULT \
> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>
> +
> +/*
> +#define R8169_PROBE_DEBUG
> +*/
> +
> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
> #define MC_FILTER_LIMIT 32
> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> {
> struct pci_dev *pdev = tp->pci_dev;
> struct mii_bus *new_bus;
> + u32 phydev_id = 0;
> + u32 phydrv_id = 0;
> + u32 phydrv_id_mask = 0;
> int ret;
>
> new_bus = devm_mdiobus_alloc(&pdev->dev);
> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> new_bus->write = r8169_mdio_write_reg;
>
> ret = mdiobus_register(new_bus);
> +
> +#ifdef R8169_PROBE_DEBUG
> + dev_info(&pdev->dev,
> + "mdiobus_register: %s, %d\n",
> + new_bus->id, ret);
> +#endif
> if (ret)
> return ret;
>
> tp->phydev = mdiobus_get_phy(new_bus, 0);
> +
> if (!tp->phydev) {
> mdiobus_unregister(new_bus);
> return -ENODEV;
> - } else if (!tp->phydev->drv) {
> - /* Most chip versions fail with the genphy driver.
> - * Therefore ensure that the dedicated PHY driver is loaded.
> - */
> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> - mdiobus_unregister(new_bus);
> - return -EUNATCH;
> + } else {
> + /* tp -> phydev ok */
> + int everything_OK = 0;
> +
> + /* Check driver id versus phy */
> +
> + if (tp->phydev->drv) {
> + u32 phydev_masked = 0xBEEFDEAD;
> + u32 drv_masked = ~0;
> + u32 phydev_match = ~0;
> + u32 drv_match = 0xDEADBEEF;
> +
> + phydev_id = tp->phydev->phy_id;
> + phydrv_id = tp->phydev->drv->phy_id;
> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
> +
> + drv_masked = phydrv_id & phydrv_id_mask;
> + phydev_masked = phydev_id & phydrv_id_mask;
> +
> +#ifdef R8169_PROBE_DEBUG
> + dev_debug(&pdev->dev,
> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
> + new_bus->id, phydev_id, phydev_masked,
> + phydrv_id, drv_masked);
> +#endif
> +
> + phydev_match = phydev_masked & drv_masked;
> + phydev_match = phydev_match == phydev_masked;
> +
> + drv_match = phydev_masked & drv_masked;
> + drv_match = drv_match == drv_masked;
> +
> +#ifdef R8169_PROBE_DEBUG
> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
> + new_bus->id, phydev_match, drv_match);
> +#endif
> +
> + everything_OK = (phydev_match == drv_match);
> + }
> +
> + if (!everything_OK) {
> + /* Most chip versions fail with the genphy driver.
> + * Therefore ensure that the dedicated PHY driver
> + * is loaded.
> + */
> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> + mdiobus_unregister(new_bus);
> + return -EUNATCH;
> + }
> }
>
> /* PHY will be woken up in rtl_open() */
> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> u64_stats_init(&tp->rx_stats.syncp);
> u64_stats_init(&tp->tx_stats.syncp);
>
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: MAC\n");
> +#endif
> +
> rtl_init_mac_address(tp);
>
> dev->ethtool_ops = &rtl8169_ethtool_ops;
> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> dev->hw_features |= NETIF_F_RXFCS;
>
> jumbo_max = rtl_jumbo_max(tp);
> +
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
> +#endif
> +
> if (jumbo_max)
> dev->max_mtu = jumbo_max;
>
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: irq mask\n");
> +#endif
> +
> rtl_set_irq_mask(tp);
>
> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
> +#endif
> +
> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
> &tp->counters_phys_addr,
> GFP_KERNEL);
> if (!tp->counters)
> return -ENOMEM;
>
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: set driver data\n");
> +#endif
> +
> pci_set_drvdata(pdev, dev);
>
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: register mdio\n");
> +#endif
> +
> rc = r8169_mdio_register(tp);
> +
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
> +#endif
> +
> if (rc)
> return rc;
>
> /* chip gets powered up in rtl_open() */
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
> +#endif
> +
> rtl_pll_power_down(tp);
>
> rc = register_netdev(dev);
> +
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
> +#endif
> +
> if (rc)
> goto err_mdio_unregister;
>
> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (pci_dev_run_wake(pdev))
> pm_runtime_put_sync(&pdev->dev);
>
> +#ifdef R816X_PROBE_DEBUG
> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
> +#endif
> +
> return 0;
>
> err_mdio_unregister:
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 522760c8bca6..41777f379a57 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
> {
> struct mdio_device *mdiodev = bus->mdio_map[addr];
> -
> + struct phy_device *rv = NULL;
> +/*
> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
> +*/
> if (!mdiodev)
> return NULL;
>
> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
> return NULL;
>
> - return container_of(mdiodev, struct phy_device, mdio);
> + rv = container_of(mdiodev, struct phy_device, mdio);
> +/*
> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
> + bus->id, addr, mdiodev, rv);
> +*/
> + return rv;
> }
> EXPORT_SYMBOL(mdiobus_get_phy);
>
> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>
> bus->state = MDIOBUS_REGISTERED;
> - pr_info("%s: probed\n", bus->name);
> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
> return 0;
>
> error:
> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
> while (--i >= 0) {
> mdiodev = bus->mdio_map[i];
> if (!mdiodev)
> --
> 2.26.0
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 12:18 ` Leon Romanovsky
@ 2020-04-13 14:44 ` Lauri Jakku
2020-04-13 15:33 ` Heiner Kallweit
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-13 14:44 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: netdev, Heiner Kallweit, nic_swsd
[-- Attachment #1: Type: text/plain, Size: 19123 bytes --]
Hi,
On 13.4.2020 15.18, Leon Romanovsky wrote:
> On Mon, Apr 13, 2020 at 03:01:23PM +0300, Lauri Jakku wrote:
>> Hi,
>>
>> I've tought that the debug's are worth to save behind an definition/commented out, so they can be enabled if needed.
>>
>
> Please stop to do top-posting.
I did not realise, sorry. Trying to do better.
>
>>
>> Latest version:
>>
>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>> From: Lauri Jakku <lja@iki.fi>
>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>
>> The driver installation determination made properly by
>> checking PHY vs DRIVER id's.
>> ---
>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>> drivers/net/phy/mdio_bus.c | 15 ++-
>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index bf5bf05970a2..5e992f285527 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -61,6 +61,11 @@
>> #define R8169_MSG_DEFAULT \
>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>
>> +
>> +/*
>> +#define R8169_PROBE_DEBUG
>> +*/
>
> Of course not, it is even worse than before.
> If user recompiles module, he will add prints.
>
> Thanks
>
New patch at the end and in attachments.
>> +
>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>> #define MC_FILTER_LIMIT 32
>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> {
>> struct pci_dev *pdev = tp->pci_dev;
>> struct mii_bus *new_bus;
>> + u32 phydev_id = 0;
>> + u32 phydrv_id = 0;
>> + u32 phydrv_id_mask = 0;
>> int ret;
>>
>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> new_bus->write = r8169_mdio_write_reg;
>>
>> ret = mdiobus_register(new_bus);
>> +
>> +#ifdef R8169_PROBE_DEBUG
>> + dev_info(&pdev->dev,
>> + "mdiobus_register: %s, %d\n",
>> + new_bus->id, ret);
>> +#endif
>> if (ret)
>> return ret;
>>
>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>> +
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is loaded.
>> - */
>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> - mdiobus_unregister(new_bus);
>> - return -EUNATCH;
>> + } else {
>> + /* tp -> phydev ok */
>> + int everything_OK = 0;
>> +
>> + /* Check driver id versus phy */
>> +
>> + if (tp->phydev->drv) {
>> + u32 phydev_masked = 0xBEEFDEAD;
>> + u32 drv_masked = ~0;
>> + u32 phydev_match = ~0;
>> + u32 drv_match = 0xDEADBEEF;
>> +
>> + phydev_id = tp->phydev->phy_id;
>> + phydrv_id = tp->phydev->drv->phy_id;
>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>> +
>> + drv_masked = phydrv_id & phydrv_id_mask;
>> + phydev_masked = phydev_id & phydrv_id_mask;
>> +
>> +#ifdef R8169_PROBE_DEBUG
>> + dev_debug(&pdev->dev,
>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>> + new_bus->id, phydev_id, phydev_masked,
>> + phydrv_id, drv_masked);
>> +#endif
>> +
>> + phydev_match = phydev_masked & drv_masked;
>> + phydev_match = phydev_match == phydev_masked;
>> +
>> + drv_match = phydev_masked & drv_masked;
>> + drv_match = drv_match == drv_masked;
>> +
>> +#ifdef R8169_PROBE_DEBUG
>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>> + new_bus->id, phydev_match, drv_match);
>> +#endif
>> +
>> + everything_OK = (phydev_match == drv_match);
>> + }
>> +
>> + if (!everything_OK) {
>> + /* Most chip versions fail with the genphy driver.
>> + * Therefore ensure that the dedicated PHY driver
>> + * is loaded.
>> + */
>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> + mdiobus_unregister(new_bus);
>> + return -EUNATCH;
>> + }
>> }
>>
>> /* PHY will be woken up in rtl_open() */
>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> u64_stats_init(&tp->rx_stats.syncp);
>> u64_stats_init(&tp->tx_stats.syncp);
>>
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: MAC\n");
>> +#endif
>> +
>> rtl_init_mac_address(tp);
>>
>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> dev->hw_features |= NETIF_F_RXFCS;
>>
>> jumbo_max = rtl_jumbo_max(tp);
>> +
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>> +#endif
>> +
>> if (jumbo_max)
>> dev->max_mtu = jumbo_max;
>>
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>> +#endif
>> +
>> rtl_set_irq_mask(tp);
>>
>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>> +#endif
>> +
>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>> &tp->counters_phys_addr,
>> GFP_KERNEL);
>> if (!tp->counters)
>> return -ENOMEM;
>>
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>> +#endif
>> +
>> pci_set_drvdata(pdev, dev);
>>
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>> +#endif
>> +
>> rc = r8169_mdio_register(tp);
>> +
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>> +#endif
>> +
>> if (rc)
>> return rc;
>>
>> /* chip gets powered up in rtl_open() */
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>> +#endif
>> +
>> rtl_pll_power_down(tp);
>>
>> rc = register_netdev(dev);
>> +
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>> +#endif
>> +
>> if (rc)
>> goto err_mdio_unregister;
>>
>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (pci_dev_run_wake(pdev))
>> pm_runtime_put_sync(&pdev->dev);
>>
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>> +#endif
>> +
>> return 0;
>>
>> err_mdio_unregister:
>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>> index 522760c8bca6..41777f379a57 100644
>> --- a/drivers/net/phy/mdio_bus.c
>> +++ b/drivers/net/phy/mdio_bus.c
>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>> {
>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>> -
>> + struct phy_device *rv = NULL;
>> +/*
>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>> +*/
>> if (!mdiodev)
>> return NULL;
>>
>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>> return NULL;
>>
>> - return container_of(mdiodev, struct phy_device, mdio);
>> + rv = container_of(mdiodev, struct phy_device, mdio);
>> +/*
>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>> + bus->id, addr, mdiodev, rv);
>> +*/
>> + return rv;
>> }
>> EXPORT_SYMBOL(mdiobus_get_phy);
>>
>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>
>> bus->state = MDIOBUS_REGISTERED;
>> - pr_info("%s: probed\n", bus->name);
>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>> return 0;
>>
>> error:
>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>> while (--i >= 0) {
>> mdiodev = bus->mdio_map[i];
>> if (!mdiodev)
>> --
>> 2.26.0
>>
>>
>>
>>
>> On 2020-04-13 14:34, Leon Romanovsky wrote:
>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> Comments inline.
>>>>
>>>> On 2020-04-13 13:58, Leon Romanovsky wrote:
>>>>> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>>>>>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>
>>>>>> The driver installation determination made properly by
>>>>>> checking PHY vs DRIVER id's.
>>>>>> ---
>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>>>>>> drivers/net/phy/mdio_bus.c | 11 +++-
>>>>>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>>>>
>>>>> I would say that most of the code is debug prints.
>>>>>
>>>>
>>>> I tought that they are helpful to keep, they are using the debug calls, so
>>>> they are not visible if user does not like those.
>>>
>>> You are missing the point of who are your users.
>>>
>>> Users want to have working device and the code. They don't need or like
>>> to debug their kernel.
>>>
>>> Thanks
>>>
>>
>> --
>> Br,
>> Lauri J.
>
>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>> From: Lauri Jakku <lja@iki.fi>
>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>
>> The driver installation determination made properly by
>> checking PHY vs DRIVER id's.
>> ---
>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>> drivers/net/phy/mdio_bus.c | 15 ++-
>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index bf5bf05970a2..5e992f285527 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -61,6 +61,11 @@
>> #define R8169_MSG_DEFAULT \
>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>
>> +
>> +/*
>> +#define R8169_PROBE_DEBUG
>> +*/
>> +
>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>> #define MC_FILTER_LIMIT 32
>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> {
>> struct pci_dev *pdev = tp->pci_dev;
>> struct mii_bus *new_bus;
>> + u32 phydev_id = 0;
>> + u32 phydrv_id = 0;
>> + u32 phydrv_id_mask = 0;
>> int ret;
>>
>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> new_bus->write = r8169_mdio_write_reg;
>>
>> ret = mdiobus_register(new_bus);
>> +
>> +#ifdef R8169_PROBE_DEBUG
>> + dev_info(&pdev->dev,
>> + "mdiobus_register: %s, %d\n",
>> + new_bus->id, ret);
>> +#endif
>> if (ret)
>> return ret;
>>
>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>> +
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is loaded.
>> - */
>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> - mdiobus_unregister(new_bus);
>> - return -EUNATCH;
>> + } else {
>> + /* tp -> phydev ok */
>> + int everything_OK = 0;
>> +
>> + /* Check driver id versus phy */
>> +
>> + if (tp->phydev->drv) {
>> + u32 phydev_masked = 0xBEEFDEAD;
>> + u32 drv_masked = ~0;
>> + u32 phydev_match = ~0;
>> + u32 drv_match = 0xDEADBEEF;
>> +
>> + phydev_id = tp->phydev->phy_id;
>> + phydrv_id = tp->phydev->drv->phy_id;
>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>> +
>> + drv_masked = phydrv_id & phydrv_id_mask;
>> + phydev_masked = phydev_id & phydrv_id_mask;
>> +
>> +#ifdef R8169_PROBE_DEBUG
>> + dev_debug(&pdev->dev,
>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>> + new_bus->id, phydev_id, phydev_masked,
>> + phydrv_id, drv_masked);
>> +#endif
>> +
>> + phydev_match = phydev_masked & drv_masked;
>> + phydev_match = phydev_match == phydev_masked;
>> +
>> + drv_match = phydev_masked & drv_masked;
>> + drv_match = drv_match == drv_masked;
>> +
>> +#ifdef R8169_PROBE_DEBUG
>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>> + new_bus->id, phydev_match, drv_match);
>> +#endif
>> +
>> + everything_OK = (phydev_match == drv_match);
>> + }
>> +
>> + if (!everything_OK) {
>> + /* Most chip versions fail with the genphy driver.
>> + * Therefore ensure that the dedicated PHY driver
>> + * is loaded.
>> + */
>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> + mdiobus_unregister(new_bus);
>> + return -EUNATCH;
>> + }
>> }
>>
>> /* PHY will be woken up in rtl_open() */
>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> u64_stats_init(&tp->rx_stats.syncp);
>> u64_stats_init(&tp->tx_stats.syncp);
>>
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: MAC\n");
>> +#endif
>> +
>> rtl_init_mac_address(tp);
>>
>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> dev->hw_features |= NETIF_F_RXFCS;
>>
>> jumbo_max = rtl_jumbo_max(tp);
>> +
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>> +#endif
>> +
>> if (jumbo_max)
>> dev->max_mtu = jumbo_max;
>>
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>> +#endif
>> +
>> rtl_set_irq_mask(tp);
>>
>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>> +#endif
>> +
>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>> &tp->counters_phys_addr,
>> GFP_KERNEL);
>> if (!tp->counters)
>> return -ENOMEM;
>>
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>> +#endif
>> +
>> pci_set_drvdata(pdev, dev);
>>
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>> +#endif
>> +
>> rc = r8169_mdio_register(tp);
>> +
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>> +#endif
>> +
>> if (rc)
>> return rc;
>>
>> /* chip gets powered up in rtl_open() */
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>> +#endif
>> +
>> rtl_pll_power_down(tp);
>>
>> rc = register_netdev(dev);
>> +
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>> +#endif
>> +
>> if (rc)
>> goto err_mdio_unregister;
>>
>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (pci_dev_run_wake(pdev))
>> pm_runtime_put_sync(&pdev->dev);
>>
>> +#ifdef R816X_PROBE_DEBUG
>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>> +#endif
>> +
>> return 0;
>>
>> err_mdio_unregister:
>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>> index 522760c8bca6..41777f379a57 100644
>> --- a/drivers/net/phy/mdio_bus.c
>> +++ b/drivers/net/phy/mdio_bus.c
>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>> {
>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>> -
>> + struct phy_device *rv = NULL;
>> +/*
>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>> +*/
>> if (!mdiodev)
>> return NULL;
>>
>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>> return NULL;
>>
>> - return container_of(mdiodev, struct phy_device, mdio);
>> + rv = container_of(mdiodev, struct phy_device, mdio);
>> +/*
>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>> + bus->id, addr, mdiodev, rv);
>> +*/
>> + return rv;
>> }
>> EXPORT_SYMBOL(mdiobus_get_phy);
>>
>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>
>> bus->state = MDIOBUS_REGISTERED;
>> - pr_info("%s: probed\n", bus->name);
>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>> return 0;
>>
>> error:
>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>> while (--i >= 0) {
>> mdiodev = bus->mdio_map[i];
>> if (!mdiodev)
>> --
>> 2.26.0
>>
>
From 85766c0ab77750faa4488ca7018784e3e8e9eba0 Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Mon, 13 Apr 2020 13:18:35 +0300
Subject: [PATCH] NET: r8168/r8169 identifying fix
The driver installation determination made properly by
checking PHY vs DRIVER id's.
---
drivers/net/ethernet/realtek/r8169_main.c | 47 +++++++++++++++++++----
1 file changed, 40 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..da08b1b1047c 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
{
struct pci_dev *pdev = tp->pci_dev;
struct mii_bus *new_bus;
+ u32 phydev_id = 0;
+ u32 phydrv_id = 0;
+ u32 phydrv_id_mask = 0;
int ret;
new_bus = devm_mdiobus_alloc(&pdev->dev);
@@ -5172,13 +5175,43 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ /* tp -> phydev ok */
+ int everything_OK = 0;
+
+ /* Check driver id versus phy */
+
+ if (tp->phydev->drv) {
+ u32 phydev_masked = 0xBEEFDEAD;
+ u32 drv_masked = ~0;
+ u32 phydev_match = ~0;
+ u32 drv_match = 0xDEADBEEF;
+
+ phydev_id = tp->phydev->phy_id;
+ phydrv_id = tp->phydev->drv->phy_id;
+ phydrv_id_mask = tp->phydev->drv->phy_id_mask;
+
+ drv_masked = phydrv_id & phydrv_id_mask;
+ phydev_masked = phydev_id & phydrv_id_mask;
+
+ phydev_match = phydev_masked & drv_masked;
+ phydev_match = phydev_match == phydev_masked;
+
+ drv_match = phydev_masked & drv_masked;
+ drv_match = drv_match == drv_masked;
+
+ everything_OK = (phydev_match == drv_match);
+ }
+
+ if (!everything_OK) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver
+ * is loaded.
+ */
+ dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
--
2.26.0
--
Br,
Lauri J.
[-- Attachment #2: NET-r8169-module-enchansments.patch --]
[-- Type: text/x-patch, Size: 2460 bytes --]
From 85766c0ab77750faa4488ca7018784e3e8e9eba0 Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Mon, 13 Apr 2020 13:18:35 +0300
Subject: [PATCH] NET: r8168/r8169 identifying fix
The driver installation determination made properly by
checking PHY vs DRIVER id's.
---
drivers/net/ethernet/realtek/r8169_main.c | 47 +++++++++++++++++++----
1 file changed, 40 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..da08b1b1047c 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
{
struct pci_dev *pdev = tp->pci_dev;
struct mii_bus *new_bus;
+ u32 phydev_id = 0;
+ u32 phydrv_id = 0;
+ u32 phydrv_id_mask = 0;
int ret;
new_bus = devm_mdiobus_alloc(&pdev->dev);
@@ -5172,13 +5175,43 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ /* tp -> phydev ok */
+ int everything_OK = 0;
+
+ /* Check driver id versus phy */
+
+ if (tp->phydev->drv) {
+ u32 phydev_masked = 0xBEEFDEAD;
+ u32 drv_masked = ~0;
+ u32 phydev_match = ~0;
+ u32 drv_match = 0xDEADBEEF;
+
+ phydev_id = tp->phydev->phy_id;
+ phydrv_id = tp->phydev->drv->phy_id;
+ phydrv_id_mask = tp->phydev->drv->phy_id_mask;
+
+ drv_masked = phydrv_id & phydrv_id_mask;
+ phydev_masked = phydev_id & phydrv_id_mask;
+
+ phydev_match = phydev_masked & drv_masked;
+ phydev_match = phydev_match == phydev_masked;
+
+ drv_match = phydev_masked & drv_masked;
+ drv_match = drv_match == drv_masked;
+
+ everything_OK = (phydev_match == drv_match);
+ }
+
+ if (!everything_OK) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver
+ * is loaded.
+ */
+ dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
--
2.26.0
^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 14:44 ` Lauri Jakku
@ 2020-04-13 15:33 ` Heiner Kallweit
2020-04-13 15:50 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Heiner Kallweit @ 2020-04-13 15:33 UTC (permalink / raw)
To: Lauri Jakku; +Cc: Leon Romanovsky, netdev, nic_swsd
On 13.04.2020 16:44, Lauri Jakku wrote:
> Hi,
>
> On 13.4.2020 15.18, Leon Romanovsky wrote:
>> On Mon, Apr 13, 2020 at 03:01:23PM +0300, Lauri Jakku wrote:
>>> Hi,
>>>
>>> I've tought that the debug's are worth to save behind an definition/commented out, so they can be enabled if needed.
>>>
>>
>> Please stop to do top-posting.
>
> I did not realise, sorry. Trying to do better.
>
>>
>>>
>>> Latest version:
>>>
>>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>>> From: Lauri Jakku <lja@iki.fi>
>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>
>>> The driver installation determination made properly by
>>> checking PHY vs DRIVER id's.
>>> ---
>>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>>> drivers/net/phy/mdio_bus.c | 15 ++-
>>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>> index bf5bf05970a2..5e992f285527 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>> @@ -61,6 +61,11 @@
>>> #define R8169_MSG_DEFAULT \
>>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>>
>>> +
>>> +/*
>>> +#define R8169_PROBE_DEBUG
>>> +*/
>>
>> Of course not, it is even worse than before.
>> If user recompiles module, he will add prints.
>>
>> Thanks
>>
>
> New patch at the end and in attachments.
>
Please do as suggested and read through the kernel developer beginners
guides first. The patch itself, and sending patches as attachments
is not acceptable.
Please provide the requested logs and information first so that we can
understand your issue.
>
>>> +
>>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>>> #define MC_FILTER_LIMIT 32
>>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>> {
>>> struct pci_dev *pdev = tp->pci_dev;
>>> struct mii_bus *new_bus;
>>> + u32 phydev_id = 0;
>>> + u32 phydrv_id = 0;
>>> + u32 phydrv_id_mask = 0;
>>> int ret;
>>>
>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>> new_bus->write = r8169_mdio_write_reg;
>>>
>>> ret = mdiobus_register(new_bus);
>>> +
>>> +#ifdef R8169_PROBE_DEBUG
>>> + dev_info(&pdev->dev,
>>> + "mdiobus_register: %s, %d\n",
>>> + new_bus->id, ret);
>>> +#endif
>>> if (ret)
>>> return ret;
>>>
>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>> +
>>> if (!tp->phydev) {
>>> mdiobus_unregister(new_bus);
>>> return -ENODEV;
>>> - } else if (!tp->phydev->drv) {
>>> - /* Most chip versions fail with the genphy driver.
>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>> - */
>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>> - mdiobus_unregister(new_bus);
>>> - return -EUNATCH;
>>> + } else {
>>> + /* tp -> phydev ok */
>>> + int everything_OK = 0;
>>> +
>>> + /* Check driver id versus phy */
>>> +
>>> + if (tp->phydev->drv) {
>>> + u32 phydev_masked = 0xBEEFDEAD;
>>> + u32 drv_masked = ~0;
>>> + u32 phydev_match = ~0;
>>> + u32 drv_match = 0xDEADBEEF;
>>> +
>>> + phydev_id = tp->phydev->phy_id;
>>> + phydrv_id = tp->phydev->drv->phy_id;
>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>> +
>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>> +
>>> +#ifdef R8169_PROBE_DEBUG
>>> + dev_debug(&pdev->dev,
>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>> + new_bus->id, phydev_id, phydev_masked,
>>> + phydrv_id, drv_masked);
>>> +#endif
>>> +
>>> + phydev_match = phydev_masked & drv_masked;
>>> + phydev_match = phydev_match == phydev_masked;
>>> +
>>> + drv_match = phydev_masked & drv_masked;
>>> + drv_match = drv_match == drv_masked;
>>> +
>>> +#ifdef R8169_PROBE_DEBUG
>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>> + new_bus->id, phydev_match, drv_match);
>>> +#endif
>>> +
>>> + everything_OK = (phydev_match == drv_match);
>>> + }
>>> +
>>> + if (!everything_OK) {
>>> + /* Most chip versions fail with the genphy driver.
>>> + * Therefore ensure that the dedicated PHY driver
>>> + * is loaded.
>>> + */
>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>> + mdiobus_unregister(new_bus);
>>> + return -EUNATCH;
>>> + }
>>> }
>>>
>>> /* PHY will be woken up in rtl_open() */
>>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> u64_stats_init(&tp->rx_stats.syncp);
>>> u64_stats_init(&tp->tx_stats.syncp);
>>>
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>> +#endif
>>> +
>>> rtl_init_mac_address(tp);
>>>
>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> dev->hw_features |= NETIF_F_RXFCS;
>>>
>>> jumbo_max = rtl_jumbo_max(tp);
>>> +
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>> +#endif
>>> +
>>> if (jumbo_max)
>>> dev->max_mtu = jumbo_max;
>>>
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>> +#endif
>>> +
>>> rtl_set_irq_mask(tp);
>>>
>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>> +#endif
>>> +
>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>> &tp->counters_phys_addr,
>>> GFP_KERNEL);
>>> if (!tp->counters)
>>> return -ENOMEM;
>>>
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>> +#endif
>>> +
>>> pci_set_drvdata(pdev, dev);
>>>
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>> +#endif
>>> +
>>> rc = r8169_mdio_register(tp);
>>> +
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>> +#endif
>>> +
>>> if (rc)
>>> return rc;
>>>
>>> /* chip gets powered up in rtl_open() */
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>> +#endif
>>> +
>>> rtl_pll_power_down(tp);
>>>
>>> rc = register_netdev(dev);
>>> +
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>> +#endif
>>> +
>>> if (rc)
>>> goto err_mdio_unregister;
>>>
>>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> if (pci_dev_run_wake(pdev))
>>> pm_runtime_put_sync(&pdev->dev);
>>>
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>> +#endif
>>> +
>>> return 0;
>>>
>>> err_mdio_unregister:
>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>> index 522760c8bca6..41777f379a57 100644
>>> --- a/drivers/net/phy/mdio_bus.c
>>> +++ b/drivers/net/phy/mdio_bus.c
>>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>> {
>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>> -
>>> + struct phy_device *rv = NULL;
>>> +/*
>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>> +*/
>>> if (!mdiodev)
>>> return NULL;
>>>
>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>> return NULL;
>>>
>>> - return container_of(mdiodev, struct phy_device, mdio);
>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>> +/*
>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>> + bus->id, addr, mdiodev, rv);
>>> +*/
>>> + return rv;
>>> }
>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>
>>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>
>>> bus->state = MDIOBUS_REGISTERED;
>>> - pr_info("%s: probed\n", bus->name);
>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>> return 0;
>>>
>>> error:
>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>> while (--i >= 0) {
>>> mdiodev = bus->mdio_map[i];
>>> if (!mdiodev)
>>> --
>>> 2.26.0
>>>
>>>
>>>
>>>
>>> On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>> Comments inline.
>>>>>
>>>>> On 2020-04-13 13:58, Leon Romanovsky wrote:
>>>>>> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>>>>>>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>>
>>>>>>> The driver installation determination made properly by
>>>>>>> checking PHY vs DRIVER id's.
>>>>>>> ---
>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>>>>>>> drivers/net/phy/mdio_bus.c | 11 +++-
>>>>>>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>>>>>
>>>>>> I would say that most of the code is debug prints.
>>>>>>
>>>>>
>>>>> I tought that they are helpful to keep, they are using the debug calls, so
>>>>> they are not visible if user does not like those.
>>>>
>>>> You are missing the point of who are your users.
>>>>
>>>> Users want to have working device and the code. They don't need or like
>>>> to debug their kernel.
>>>>
>>>> Thanks
>>>>
>>>
>>> --
>>> Br,
>>> Lauri J.
>>
>>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>>> From: Lauri Jakku <lja@iki.fi>
>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>
>>> The driver installation determination made properly by
>>> checking PHY vs DRIVER id's.
>>> ---
>>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>>> drivers/net/phy/mdio_bus.c | 15 ++-
>>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>> index bf5bf05970a2..5e992f285527 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>> @@ -61,6 +61,11 @@
>>> #define R8169_MSG_DEFAULT \
>>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>>
>>> +
>>> +/*
>>> +#define R8169_PROBE_DEBUG
>>> +*/
>>> +
>>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>>> #define MC_FILTER_LIMIT 32
>>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>> {
>>> struct pci_dev *pdev = tp->pci_dev;
>>> struct mii_bus *new_bus;
>>> + u32 phydev_id = 0;
>>> + u32 phydrv_id = 0;
>>> + u32 phydrv_id_mask = 0;
>>> int ret;
>>>
>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>> new_bus->write = r8169_mdio_write_reg;
>>>
>>> ret = mdiobus_register(new_bus);
>>> +
>>> +#ifdef R8169_PROBE_DEBUG
>>> + dev_info(&pdev->dev,
>>> + "mdiobus_register: %s, %d\n",
>>> + new_bus->id, ret);
>>> +#endif
>>> if (ret)
>>> return ret;
>>>
>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>> +
>>> if (!tp->phydev) {
>>> mdiobus_unregister(new_bus);
>>> return -ENODEV;
>>> - } else if (!tp->phydev->drv) {
>>> - /* Most chip versions fail with the genphy driver.
>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>> - */
>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>> - mdiobus_unregister(new_bus);
>>> - return -EUNATCH;
>>> + } else {
>>> + /* tp -> phydev ok */
>>> + int everything_OK = 0;
>>> +
>>> + /* Check driver id versus phy */
>>> +
>>> + if (tp->phydev->drv) {
>>> + u32 phydev_masked = 0xBEEFDEAD;
>>> + u32 drv_masked = ~0;
>>> + u32 phydev_match = ~0;
>>> + u32 drv_match = 0xDEADBEEF;
>>> +
>>> + phydev_id = tp->phydev->phy_id;
>>> + phydrv_id = tp->phydev->drv->phy_id;
>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>> +
>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>> +
>>> +#ifdef R8169_PROBE_DEBUG
>>> + dev_debug(&pdev->dev,
>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>> + new_bus->id, phydev_id, phydev_masked,
>>> + phydrv_id, drv_masked);
>>> +#endif
>>> +
>>> + phydev_match = phydev_masked & drv_masked;
>>> + phydev_match = phydev_match == phydev_masked;
>>> +
>>> + drv_match = phydev_masked & drv_masked;
>>> + drv_match = drv_match == drv_masked;
>>> +
>>> +#ifdef R8169_PROBE_DEBUG
>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>> + new_bus->id, phydev_match, drv_match);
>>> +#endif
>>> +
>>> + everything_OK = (phydev_match == drv_match);
>>> + }
>>> +
>>> + if (!everything_OK) {
>>> + /* Most chip versions fail with the genphy driver.
>>> + * Therefore ensure that the dedicated PHY driver
>>> + * is loaded.
>>> + */
>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>> + mdiobus_unregister(new_bus);
>>> + return -EUNATCH;
>>> + }
>>> }
>>>
>>> /* PHY will be woken up in rtl_open() */
>>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> u64_stats_init(&tp->rx_stats.syncp);
>>> u64_stats_init(&tp->tx_stats.syncp);
>>>
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>> +#endif
>>> +
>>> rtl_init_mac_address(tp);
>>>
>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> dev->hw_features |= NETIF_F_RXFCS;
>>>
>>> jumbo_max = rtl_jumbo_max(tp);
>>> +
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>> +#endif
>>> +
>>> if (jumbo_max)
>>> dev->max_mtu = jumbo_max;
>>>
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>> +#endif
>>> +
>>> rtl_set_irq_mask(tp);
>>>
>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>> +#endif
>>> +
>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>> &tp->counters_phys_addr,
>>> GFP_KERNEL);
>>> if (!tp->counters)
>>> return -ENOMEM;
>>>
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>> +#endif
>>> +
>>> pci_set_drvdata(pdev, dev);
>>>
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>> +#endif
>>> +
>>> rc = r8169_mdio_register(tp);
>>> +
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>> +#endif
>>> +
>>> if (rc)
>>> return rc;
>>>
>>> /* chip gets powered up in rtl_open() */
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>> +#endif
>>> +
>>> rtl_pll_power_down(tp);
>>>
>>> rc = register_netdev(dev);
>>> +
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>> +#endif
>>> +
>>> if (rc)
>>> goto err_mdio_unregister;
>>>
>>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> if (pci_dev_run_wake(pdev))
>>> pm_runtime_put_sync(&pdev->dev);
>>>
>>> +#ifdef R816X_PROBE_DEBUG
>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>> +#endif
>>> +
>>> return 0;
>>>
>>> err_mdio_unregister:
>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>> index 522760c8bca6..41777f379a57 100644
>>> --- a/drivers/net/phy/mdio_bus.c
>>> +++ b/drivers/net/phy/mdio_bus.c
>>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>> {
>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>> -
>>> + struct phy_device *rv = NULL;
>>> +/*
>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>> +*/
>>> if (!mdiodev)
>>> return NULL;
>>>
>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>> return NULL;
>>>
>>> - return container_of(mdiodev, struct phy_device, mdio);
>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>> +/*
>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>> + bus->id, addr, mdiodev, rv);
>>> +*/
>>> + return rv;
>>> }
>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>
>>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>
>>> bus->state = MDIOBUS_REGISTERED;
>>> - pr_info("%s: probed\n", bus->name);
>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>> return 0;
>>>
>>> error:
>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>> while (--i >= 0) {
>>> mdiodev = bus->mdio_map[i];
>>> if (!mdiodev)
>>> --
>>> 2.26.0
>>>
>>
>
>>From 85766c0ab77750faa4488ca7018784e3e8e9eba0 Mon Sep 17 00:00:00 2001
> From: Lauri Jakku <lja@iki.fi>
> Date: Mon, 13 Apr 2020 13:18:35 +0300
> Subject: [PATCH] NET: r8168/r8169 identifying fix
>
> The driver installation determination made properly by
> checking PHY vs DRIVER id's.
> ---
> drivers/net/ethernet/realtek/r8169_main.c | 47 +++++++++++++++++++----
> 1 file changed, 40 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index bf5bf05970a2..da08b1b1047c 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> {
> struct pci_dev *pdev = tp->pci_dev;
> struct mii_bus *new_bus;
> + u32 phydev_id = 0;
> + u32 phydrv_id = 0;
> + u32 phydrv_id_mask = 0;
> int ret;
>
> new_bus = devm_mdiobus_alloc(&pdev->dev);
> @@ -5172,13 +5175,43 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> if (!tp->phydev) {
> mdiobus_unregister(new_bus);
> return -ENODEV;
> - } else if (!tp->phydev->drv) {
> - /* Most chip versions fail with the genphy driver.
> - * Therefore ensure that the dedicated PHY driver is loaded.
> - */
> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> - mdiobus_unregister(new_bus);
> - return -EUNATCH;
> + } else {
> + /* tp -> phydev ok */
> + int everything_OK = 0;
> +
> + /* Check driver id versus phy */
> +
> + if (tp->phydev->drv) {
> + u32 phydev_masked = 0xBEEFDEAD;
> + u32 drv_masked = ~0;
> + u32 phydev_match = ~0;
> + u32 drv_match = 0xDEADBEEF;
> +
> + phydev_id = tp->phydev->phy_id;
> + phydrv_id = tp->phydev->drv->phy_id;
> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
> +
> + drv_masked = phydrv_id & phydrv_id_mask;
> + phydev_masked = phydev_id & phydrv_id_mask;
> +
> + phydev_match = phydev_masked & drv_masked;
> + phydev_match = phydev_match == phydev_masked;
> +
> + drv_match = phydev_masked & drv_masked;
> + drv_match = drv_match == drv_masked;
> +
> + everything_OK = (phydev_match == drv_match);
> + }
> +
> + if (!everything_OK) {
> + /* Most chip versions fail with the genphy driver.
> + * Therefore ensure that the dedicated PHY driver
> + * is loaded.
> + */
> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> + mdiobus_unregister(new_bus);
> + return -EUNATCH;
> + }
> }
>
> /* PHY will be woken up in rtl_open() */
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 15:33 ` Heiner Kallweit
@ 2020-04-13 15:50 ` Lauri Jakku
2020-04-13 15:54 ` Heiner Kallweit
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-13 15:50 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 13.4.2020 18.33, Heiner Kallweit wrote:
> On 13.04.2020 16:44, Lauri Jakku wrote:
>> Hi,
>>
>> On 13.4.2020 15.18, Leon Romanovsky wrote:
>>> On Mon, Apr 13, 2020 at 03:01:23PM +0300, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> I've tought that the debug's are worth to save behind an definition/commented out, so they can be enabled if needed.
>>>>
>>>
>>> Please stop to do top-posting.
>>
>> I did not realise, sorry. Trying to do better.
>>
>>>
>>>>
>>>> Latest version:
>>>>
>>>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>>>> From: Lauri Jakku <lja@iki.fi>
>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>
>>>> The driver installation determination made properly by
>>>> checking PHY vs DRIVER id's.
>>>> ---
>>>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>>>> drivers/net/phy/mdio_bus.c | 15 ++-
>>>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>> index bf5bf05970a2..5e992f285527 100644
>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>> @@ -61,6 +61,11 @@
>>>> #define R8169_MSG_DEFAULT \
>>>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>>>
>>>> +
>>>> +/*
>>>> +#define R8169_PROBE_DEBUG
>>>> +*/
>>>
>>> Of course not, it is even worse than before.
>>> If user recompiles module, he will add prints.
>>>
>>> Thanks
>>>
>>
>> New patch at the end and in attachments.
>>
> Please do as suggested and read through the kernel developer beginners
> guides first. The patch itself, and sending patches as attachments
> is not acceptable.
>
> Please provide the requested logs and information first so that we can
> understand your issue.
>
I'm compiling newest patch + 5.6.2-2 and I'll then provide logs from
5.3, 5.4 and 5.6 (without and with the patch).
steps i take:
1. power off computer properly
2. take output of dmesg
3. take output of ip link
Initramfs does have libphy, realtek and r8169 modules added.
This wille take some time, i try to provide the logs today.
Do you like if they are provided in tar per configuration, or
how ?
I make the commit message have log of problem and log of solution
case.
>>
>>>> +
>>>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>>>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>>>> #define MC_FILTER_LIMIT 32
>>>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>> {
>>>> struct pci_dev *pdev = tp->pci_dev;
>>>> struct mii_bus *new_bus;
>>>> + u32 phydev_id = 0;
>>>> + u32 phydrv_id = 0;
>>>> + u32 phydrv_id_mask = 0;
>>>> int ret;
>>>>
>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>> new_bus->write = r8169_mdio_write_reg;
>>>>
>>>> ret = mdiobus_register(new_bus);
>>>> +
>>>> +#ifdef R8169_PROBE_DEBUG
>>>> + dev_info(&pdev->dev,
>>>> + "mdiobus_register: %s, %d\n",
>>>> + new_bus->id, ret);
>>>> +#endif
>>>> if (ret)
>>>> return ret;
>>>>
>>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>>> +
>>>> if (!tp->phydev) {
>>>> mdiobus_unregister(new_bus);
>>>> return -ENODEV;
>>>> - } else if (!tp->phydev->drv) {
>>>> - /* Most chip versions fail with the genphy driver.
>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>> - */
>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>> - mdiobus_unregister(new_bus);
>>>> - return -EUNATCH;
>>>> + } else {
>>>> + /* tp -> phydev ok */
>>>> + int everything_OK = 0;
>>>> +
>>>> + /* Check driver id versus phy */
>>>> +
>>>> + if (tp->phydev->drv) {
>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>> + u32 drv_masked = ~0;
>>>> + u32 phydev_match = ~0;
>>>> + u32 drv_match = 0xDEADBEEF;
>>>> +
>>>> + phydev_id = tp->phydev->phy_id;
>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>> +
>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>> +
>>>> +#ifdef R8169_PROBE_DEBUG
>>>> + dev_debug(&pdev->dev,
>>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>>> + new_bus->id, phydev_id, phydev_masked,
>>>> + phydrv_id, drv_masked);
>>>> +#endif
>>>> +
>>>> + phydev_match = phydev_masked & drv_masked;
>>>> + phydev_match = phydev_match == phydev_masked;
>>>> +
>>>> + drv_match = phydev_masked & drv_masked;
>>>> + drv_match = drv_match == drv_masked;
>>>> +
>>>> +#ifdef R8169_PROBE_DEBUG
>>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>>> + new_bus->id, phydev_match, drv_match);
>>>> +#endif
>>>> +
>>>> + everything_OK = (phydev_match == drv_match);
>>>> + }
>>>> +
>>>> + if (!everything_OK) {
>>>> + /* Most chip versions fail with the genphy driver.
>>>> + * Therefore ensure that the dedicated PHY driver
>>>> + * is loaded.
>>>> + */
>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>> + mdiobus_unregister(new_bus);
>>>> + return -EUNATCH;
>>>> + }
>>>> }
>>>>
>>>> /* PHY will be woken up in rtl_open() */
>>>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> u64_stats_init(&tp->rx_stats.syncp);
>>>> u64_stats_init(&tp->tx_stats.syncp);
>>>>
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>>> +#endif
>>>> +
>>>> rtl_init_mac_address(tp);
>>>>
>>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> dev->hw_features |= NETIF_F_RXFCS;
>>>>
>>>> jumbo_max = rtl_jumbo_max(tp);
>>>> +
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>>> +#endif
>>>> +
>>>> if (jumbo_max)
>>>> dev->max_mtu = jumbo_max;
>>>>
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>>> +#endif
>>>> +
>>>> rtl_set_irq_mask(tp);
>>>>
>>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>>
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>>> +#endif
>>>> +
>>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>>> &tp->counters_phys_addr,
>>>> GFP_KERNEL);
>>>> if (!tp->counters)
>>>> return -ENOMEM;
>>>>
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>>> +#endif
>>>> +
>>>> pci_set_drvdata(pdev, dev);
>>>>
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>>> +#endif
>>>> +
>>>> rc = r8169_mdio_register(tp);
>>>> +
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>>> +#endif
>>>> +
>>>> if (rc)
>>>> return rc;
>>>>
>>>> /* chip gets powered up in rtl_open() */
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>>> +#endif
>>>> +
>>>> rtl_pll_power_down(tp);
>>>>
>>>> rc = register_netdev(dev);
>>>> +
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>>> +#endif
>>>> +
>>>> if (rc)
>>>> goto err_mdio_unregister;
>>>>
>>>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> if (pci_dev_run_wake(pdev))
>>>> pm_runtime_put_sync(&pdev->dev);
>>>>
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>>> +#endif
>>>> +
>>>> return 0;
>>>>
>>>> err_mdio_unregister:
>>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>>> index 522760c8bca6..41777f379a57 100644
>>>> --- a/drivers/net/phy/mdio_bus.c
>>>> +++ b/drivers/net/phy/mdio_bus.c
>>>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>>> {
>>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>>> -
>>>> + struct phy_device *rv = NULL;
>>>> +/*
>>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>>> +*/
>>>> if (!mdiodev)
>>>> return NULL;
>>>>
>>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>>> return NULL;
>>>>
>>>> - return container_of(mdiodev, struct phy_device, mdio);
>>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>>> +/*
>>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>>> + bus->id, addr, mdiodev, rv);
>>>> +*/
>>>> + return rv;
>>>> }
>>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>>
>>>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>>
>>>> bus->state = MDIOBUS_REGISTERED;
>>>> - pr_info("%s: probed\n", bus->name);
>>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>>> return 0;
>>>>
>>>> error:
>>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>>> while (--i >= 0) {
>>>> mdiodev = bus->mdio_map[i];
>>>> if (!mdiodev)
>>>> --
>>>> 2.26.0
>>>>
>>>>
>>>>
>>>>
>>>> On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Comments inline.
>>>>>>
>>>>>> On 2020-04-13 13:58, Leon Romanovsky wrote:
>>>>>>> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>>>>>>>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>>>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>>>
>>>>>>>> The driver installation determination made properly by
>>>>>>>> checking PHY vs DRIVER id's.
>>>>>>>> ---
>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>>>>>>>> drivers/net/phy/mdio_bus.c | 11 +++-
>>>>>>>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>>>>>>
>>>>>>> I would say that most of the code is debug prints.
>>>>>>>
>>>>>>
>>>>>> I tought that they are helpful to keep, they are using the debug calls, so
>>>>>> they are not visible if user does not like those.
>>>>>
>>>>> You are missing the point of who are your users.
>>>>>
>>>>> Users want to have working device and the code. They don't need or like
>>>>> to debug their kernel.
>>>>>
>>>>> Thanks
>>>>>
>>>>
>>>> --
>>>> Br,
>>>> Lauri J.
>>>
>>>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>>>> From: Lauri Jakku <lja@iki.fi>
>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>
>>>> The driver installation determination made properly by
>>>> checking PHY vs DRIVER id's.
>>>> ---
>>>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>>>> drivers/net/phy/mdio_bus.c | 15 ++-
>>>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>> index bf5bf05970a2..5e992f285527 100644
>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>> @@ -61,6 +61,11 @@
>>>> #define R8169_MSG_DEFAULT \
>>>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>>>
>>>> +
>>>> +/*
>>>> +#define R8169_PROBE_DEBUG
>>>> +*/
>>>> +
>>>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>>>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>>>> #define MC_FILTER_LIMIT 32
>>>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>> {
>>>> struct pci_dev *pdev = tp->pci_dev;
>>>> struct mii_bus *new_bus;
>>>> + u32 phydev_id = 0;
>>>> + u32 phydrv_id = 0;
>>>> + u32 phydrv_id_mask = 0;
>>>> int ret;
>>>>
>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>> new_bus->write = r8169_mdio_write_reg;
>>>>
>>>> ret = mdiobus_register(new_bus);
>>>> +
>>>> +#ifdef R8169_PROBE_DEBUG
>>>> + dev_info(&pdev->dev,
>>>> + "mdiobus_register: %s, %d\n",
>>>> + new_bus->id, ret);
>>>> +#endif
>>>> if (ret)
>>>> return ret;
>>>>
>>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>>> +
>>>> if (!tp->phydev) {
>>>> mdiobus_unregister(new_bus);
>>>> return -ENODEV;
>>>> - } else if (!tp->phydev->drv) {
>>>> - /* Most chip versions fail with the genphy driver.
>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>> - */
>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>> - mdiobus_unregister(new_bus);
>>>> - return -EUNATCH;
>>>> + } else {
>>>> + /* tp -> phydev ok */
>>>> + int everything_OK = 0;
>>>> +
>>>> + /* Check driver id versus phy */
>>>> +
>>>> + if (tp->phydev->drv) {
>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>> + u32 drv_masked = ~0;
>>>> + u32 phydev_match = ~0;
>>>> + u32 drv_match = 0xDEADBEEF;
>>>> +
>>>> + phydev_id = tp->phydev->phy_id;
>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>> +
>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>> +
>>>> +#ifdef R8169_PROBE_DEBUG
>>>> + dev_debug(&pdev->dev,
>>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>>> + new_bus->id, phydev_id, phydev_masked,
>>>> + phydrv_id, drv_masked);
>>>> +#endif
>>>> +
>>>> + phydev_match = phydev_masked & drv_masked;
>>>> + phydev_match = phydev_match == phydev_masked;
>>>> +
>>>> + drv_match = phydev_masked & drv_masked;
>>>> + drv_match = drv_match == drv_masked;
>>>> +
>>>> +#ifdef R8169_PROBE_DEBUG
>>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>>> + new_bus->id, phydev_match, drv_match);
>>>> +#endif
>>>> +
>>>> + everything_OK = (phydev_match == drv_match);
>>>> + }
>>>> +
>>>> + if (!everything_OK) {
>>>> + /* Most chip versions fail with the genphy driver.
>>>> + * Therefore ensure that the dedicated PHY driver
>>>> + * is loaded.
>>>> + */
>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>> + mdiobus_unregister(new_bus);
>>>> + return -EUNATCH;
>>>> + }
>>>> }
>>>>
>>>> /* PHY will be woken up in rtl_open() */
>>>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> u64_stats_init(&tp->rx_stats.syncp);
>>>> u64_stats_init(&tp->tx_stats.syncp);
>>>>
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>>> +#endif
>>>> +
>>>> rtl_init_mac_address(tp);
>>>>
>>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> dev->hw_features |= NETIF_F_RXFCS;
>>>>
>>>> jumbo_max = rtl_jumbo_max(tp);
>>>> +
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>>> +#endif
>>>> +
>>>> if (jumbo_max)
>>>> dev->max_mtu = jumbo_max;
>>>>
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>>> +#endif
>>>> +
>>>> rtl_set_irq_mask(tp);
>>>>
>>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>>
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>>> +#endif
>>>> +
>>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>>> &tp->counters_phys_addr,
>>>> GFP_KERNEL);
>>>> if (!tp->counters)
>>>> return -ENOMEM;
>>>>
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>>> +#endif
>>>> +
>>>> pci_set_drvdata(pdev, dev);
>>>>
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>>> +#endif
>>>> +
>>>> rc = r8169_mdio_register(tp);
>>>> +
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>>> +#endif
>>>> +
>>>> if (rc)
>>>> return rc;
>>>>
>>>> /* chip gets powered up in rtl_open() */
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>>> +#endif
>>>> +
>>>> rtl_pll_power_down(tp);
>>>>
>>>> rc = register_netdev(dev);
>>>> +
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>>> +#endif
>>>> +
>>>> if (rc)
>>>> goto err_mdio_unregister;
>>>>
>>>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> if (pci_dev_run_wake(pdev))
>>>> pm_runtime_put_sync(&pdev->dev);
>>>>
>>>> +#ifdef R816X_PROBE_DEBUG
>>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>>> +#endif
>>>> +
>>>> return 0;
>>>>
>>>> err_mdio_unregister:
>>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>>> index 522760c8bca6..41777f379a57 100644
>>>> --- a/drivers/net/phy/mdio_bus.c
>>>> +++ b/drivers/net/phy/mdio_bus.c
>>>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>>> {
>>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>>> -
>>>> + struct phy_device *rv = NULL;
>>>> +/*
>>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>>> +*/
>>>> if (!mdiodev)
>>>> return NULL;
>>>>
>>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>>> return NULL;
>>>>
>>>> - return container_of(mdiodev, struct phy_device, mdio);
>>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>>> +/*
>>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>>> + bus->id, addr, mdiodev, rv);
>>>> +*/
>>>> + return rv;
>>>> }
>>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>>
>>>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>>
>>>> bus->state = MDIOBUS_REGISTERED;
>>>> - pr_info("%s: probed\n", bus->name);
>>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>>> return 0;
>>>>
>>>> error:
>>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>>> while (--i >= 0) {
>>>> mdiodev = bus->mdio_map[i];
>>>> if (!mdiodev)
>>>> --
>>>> 2.26.0
>>>>
>>>
>>
>> >From 85766c0ab77750faa4488ca7018784e3e8e9eba0 Mon Sep 17 00:00:00 2001
>> From: Lauri Jakku <lja@iki.fi>
>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>
>> The driver installation determination made properly by
>> checking PHY vs DRIVER id's.
>> ---
>> drivers/net/ethernet/realtek/r8169_main.c | 47 +++++++++++++++++++----
>> 1 file changed, 40 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index bf5bf05970a2..da08b1b1047c 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> {
>> struct pci_dev *pdev = tp->pci_dev;
>> struct mii_bus *new_bus;
>> + u32 phydev_id = 0;
>> + u32 phydrv_id = 0;
>> + u32 phydrv_id_mask = 0;
>> int ret;
>>
>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>> @@ -5172,13 +5175,43 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is loaded.
>> - */
>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> - mdiobus_unregister(new_bus);
>> - return -EUNATCH;
>> + } else {
>> + /* tp -> phydev ok */
>> + int everything_OK = 0;
>> +
>> + /* Check driver id versus phy */
>> +
>> + if (tp->phydev->drv) {
>> + u32 phydev_masked = 0xBEEFDEAD;
>> + u32 drv_masked = ~0;
>> + u32 phydev_match = ~0;
>> + u32 drv_match = 0xDEADBEEF;
>> +
>> + phydev_id = tp->phydev->phy_id;
>> + phydrv_id = tp->phydev->drv->phy_id;
>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>> +
>> + drv_masked = phydrv_id & phydrv_id_mask;
>> + phydev_masked = phydev_id & phydrv_id_mask;
>> +
>> + phydev_match = phydev_masked & drv_masked;
>> + phydev_match = phydev_match == phydev_masked;
>> +
>> + drv_match = phydev_masked & drv_masked;
>> + drv_match = drv_match == drv_masked;
>> +
>> + everything_OK = (phydev_match == drv_match);
>> + }
>> +
>> + if (!everything_OK) {
>> + /* Most chip versions fail with the genphy driver.
>> + * Therefore ensure that the dedicated PHY driver
>> + * is loaded.
>> + */
>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> + mdiobus_unregister(new_bus);
>> + return -EUNATCH;
>> + }
>> }
>>
>> /* PHY will be woken up in rtl_open() */
>>
>
>
--
Br,
Lauri J.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 15:50 ` Lauri Jakku
@ 2020-04-13 15:54 ` Heiner Kallweit
2020-04-13 16:10 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Heiner Kallweit @ 2020-04-13 15:54 UTC (permalink / raw)
To: Lauri Jakku; +Cc: Leon Romanovsky, netdev, nic_swsd
On 13.04.2020 17:50, Lauri Jakku wrote:
> Hi,
>
> On 13.4.2020 18.33, Heiner Kallweit wrote:
>> On 13.04.2020 16:44, Lauri Jakku wrote:
>>> Hi,
>>>
>>> On 13.4.2020 15.18, Leon Romanovsky wrote:
>>>> On Mon, Apr 13, 2020 at 03:01:23PM +0300, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>> I've tought that the debug's are worth to save behind an definition/commented out, so they can be enabled if needed.
>>>>>
>>>>
>>>> Please stop to do top-posting.
>>>
>>> I did not realise, sorry. Trying to do better.
>>>
>>>>
>>>>>
>>>>> Latest version:
>>>>>
>>>>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>
>>>>> The driver installation determination made properly by
>>>>> checking PHY vs DRIVER id's.
>>>>> ---
>>>>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>>>>> drivers/net/phy/mdio_bus.c | 15 ++-
>>>>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>> index bf5bf05970a2..5e992f285527 100644
>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>> @@ -61,6 +61,11 @@
>>>>> #define R8169_MSG_DEFAULT \
>>>>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>>>>
>>>>> +
>>>>> +/*
>>>>> +#define R8169_PROBE_DEBUG
>>>>> +*/
>>>>
>>>> Of course not, it is even worse than before.
>>>> If user recompiles module, he will add prints.
>>>>
>>>> Thanks
>>>>
>>>
>>> New patch at the end and in attachments.
>>>
>> Please do as suggested and read through the kernel developer beginners
>> guides first. The patch itself, and sending patches as attachments
>> is not acceptable.
>>
>> Please provide the requested logs and information first so that we can
>> understand your issue.
>>
>
> I'm compiling newest patch + 5.6.2-2 and I'll then provide logs from
> 5.3, 5.4 and 5.6 (without and with the patch).
>
> steps i take:
> 1. power off computer properly
> 2. take output of dmesg
> 3. take output of ip link
>
> Initramfs does have libphy, realtek and r8169 modules added.
>
Typically you need the network driver in initramfs only when
loading rootfs from network, e.g. via NFS.
How is it if you remove r8169 from initramfs?
> This wille take some time, i try to provide the logs today.
>
> Do you like if they are provided in tar per configuration, or
> how ?
>
The logs you can attach to the mail (name them properly).
> I make the commit message have log of problem and log of solution
> case.
>
>
>>>
>>>>> +
>>>>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>>>>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>>>>> #define MC_FILTER_LIMIT 32
>>>>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>> {
>>>>> struct pci_dev *pdev = tp->pci_dev;
>>>>> struct mii_bus *new_bus;
>>>>> + u32 phydev_id = 0;
>>>>> + u32 phydrv_id = 0;
>>>>> + u32 phydrv_id_mask = 0;
>>>>> int ret;
>>>>>
>>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>> new_bus->write = r8169_mdio_write_reg;
>>>>>
>>>>> ret = mdiobus_register(new_bus);
>>>>> +
>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>> + dev_info(&pdev->dev,
>>>>> + "mdiobus_register: %s, %d\n",
>>>>> + new_bus->id, ret);
>>>>> +#endif
>>>>> if (ret)
>>>>> return ret;
>>>>>
>>>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>>>> +
>>>>> if (!tp->phydev) {
>>>>> mdiobus_unregister(new_bus);
>>>>> return -ENODEV;
>>>>> - } else if (!tp->phydev->drv) {
>>>>> - /* Most chip versions fail with the genphy driver.
>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>> - */
>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>> - mdiobus_unregister(new_bus);
>>>>> - return -EUNATCH;
>>>>> + } else {
>>>>> + /* tp -> phydev ok */
>>>>> + int everything_OK = 0;
>>>>> +
>>>>> + /* Check driver id versus phy */
>>>>> +
>>>>> + if (tp->phydev->drv) {
>>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>>> + u32 drv_masked = ~0;
>>>>> + u32 phydev_match = ~0;
>>>>> + u32 drv_match = 0xDEADBEEF;
>>>>> +
>>>>> + phydev_id = tp->phydev->phy_id;
>>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>>> +
>>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>>> +
>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>> + dev_debug(&pdev->dev,
>>>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>>>> + new_bus->id, phydev_id, phydev_masked,
>>>>> + phydrv_id, drv_masked);
>>>>> +#endif
>>>>> +
>>>>> + phydev_match = phydev_masked & drv_masked;
>>>>> + phydev_match = phydev_match == phydev_masked;
>>>>> +
>>>>> + drv_match = phydev_masked & drv_masked;
>>>>> + drv_match = drv_match == drv_masked;
>>>>> +
>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>>>> + new_bus->id, phydev_match, drv_match);
>>>>> +#endif
>>>>> +
>>>>> + everything_OK = (phydev_match == drv_match);
>>>>> + }
>>>>> +
>>>>> + if (!everything_OK) {
>>>>> + /* Most chip versions fail with the genphy driver.
>>>>> + * Therefore ensure that the dedicated PHY driver
>>>>> + * is loaded.
>>>>> + */
>>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>> + mdiobus_unregister(new_bus);
>>>>> + return -EUNATCH;
>>>>> + }
>>>>> }
>>>>>
>>>>> /* PHY will be woken up in rtl_open() */
>>>>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>> u64_stats_init(&tp->rx_stats.syncp);
>>>>> u64_stats_init(&tp->tx_stats.syncp);
>>>>>
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>>>> +#endif
>>>>> +
>>>>> rtl_init_mac_address(tp);
>>>>>
>>>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>>>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>> dev->hw_features |= NETIF_F_RXFCS;
>>>>>
>>>>> jumbo_max = rtl_jumbo_max(tp);
>>>>> +
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>>>> +#endif
>>>>> +
>>>>> if (jumbo_max)
>>>>> dev->max_mtu = jumbo_max;
>>>>>
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>>>> +#endif
>>>>> +
>>>>> rtl_set_irq_mask(tp);
>>>>>
>>>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>>>
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>>>> +#endif
>>>>> +
>>>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>>>> &tp->counters_phys_addr,
>>>>> GFP_KERNEL);
>>>>> if (!tp->counters)
>>>>> return -ENOMEM;
>>>>>
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>>>> +#endif
>>>>> +
>>>>> pci_set_drvdata(pdev, dev);
>>>>>
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>>>> +#endif
>>>>> +
>>>>> rc = r8169_mdio_register(tp);
>>>>> +
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>>>> +#endif
>>>>> +
>>>>> if (rc)
>>>>> return rc;
>>>>>
>>>>> /* chip gets powered up in rtl_open() */
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>>>> +#endif
>>>>> +
>>>>> rtl_pll_power_down(tp);
>>>>>
>>>>> rc = register_netdev(dev);
>>>>> +
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>>>> +#endif
>>>>> +
>>>>> if (rc)
>>>>> goto err_mdio_unregister;
>>>>>
>>>>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>> if (pci_dev_run_wake(pdev))
>>>>> pm_runtime_put_sync(&pdev->dev);
>>>>>
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>>>> +#endif
>>>>> +
>>>>> return 0;
>>>>>
>>>>> err_mdio_unregister:
>>>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>>>> index 522760c8bca6..41777f379a57 100644
>>>>> --- a/drivers/net/phy/mdio_bus.c
>>>>> +++ b/drivers/net/phy/mdio_bus.c
>>>>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>>>> {
>>>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>>>> -
>>>>> + struct phy_device *rv = NULL;
>>>>> +/*
>>>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>>>> +*/
>>>>> if (!mdiodev)
>>>>> return NULL;
>>>>>
>>>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>>>> return NULL;
>>>>>
>>>>> - return container_of(mdiodev, struct phy_device, mdio);
>>>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>>>> +/*
>>>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>>>> + bus->id, addr, mdiodev, rv);
>>>>> +*/
>>>>> + return rv;
>>>>> }
>>>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>>>
>>>>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>>>
>>>>> bus->state = MDIOBUS_REGISTERED;
>>>>> - pr_info("%s: probed\n", bus->name);
>>>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>>>> return 0;
>>>>>
>>>>> error:
>>>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>>>> while (--i >= 0) {
>>>>> mdiodev = bus->mdio_map[i];
>>>>> if (!mdiodev)
>>>>> --
>>>>> 2.26.0
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Comments inline.
>>>>>>>
>>>>>>> On 2020-04-13 13:58, Leon Romanovsky wrote:
>>>>>>>> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>>>>>>>>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>>>>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>>>>
>>>>>>>>> The driver installation determination made properly by
>>>>>>>>> checking PHY vs DRIVER id's.
>>>>>>>>> ---
>>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>>>>>>>>> drivers/net/phy/mdio_bus.c | 11 +++-
>>>>>>>>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>>>>>>>
>>>>>>>> I would say that most of the code is debug prints.
>>>>>>>>
>>>>>>>
>>>>>>> I tought that they are helpful to keep, they are using the debug calls, so
>>>>>>> they are not visible if user does not like those.
>>>>>>
>>>>>> You are missing the point of who are your users.
>>>>>>
>>>>>> Users want to have working device and the code. They don't need or like
>>>>>> to debug their kernel.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>
>>>>> --
>>>>> Br,
>>>>> Lauri J.
>>>>
>>>>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>
>>>>> The driver installation determination made properly by
>>>>> checking PHY vs DRIVER id's.
>>>>> ---
>>>>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>>>>> drivers/net/phy/mdio_bus.c | 15 ++-
>>>>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>> index bf5bf05970a2..5e992f285527 100644
>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>> @@ -61,6 +61,11 @@
>>>>> #define R8169_MSG_DEFAULT \
>>>>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>>>>
>>>>> +
>>>>> +/*
>>>>> +#define R8169_PROBE_DEBUG
>>>>> +*/
>>>>> +
>>>>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>>>>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>>>>> #define MC_FILTER_LIMIT 32
>>>>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>> {
>>>>> struct pci_dev *pdev = tp->pci_dev;
>>>>> struct mii_bus *new_bus;
>>>>> + u32 phydev_id = 0;
>>>>> + u32 phydrv_id = 0;
>>>>> + u32 phydrv_id_mask = 0;
>>>>> int ret;
>>>>>
>>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>> new_bus->write = r8169_mdio_write_reg;
>>>>>
>>>>> ret = mdiobus_register(new_bus);
>>>>> +
>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>> + dev_info(&pdev->dev,
>>>>> + "mdiobus_register: %s, %d\n",
>>>>> + new_bus->id, ret);
>>>>> +#endif
>>>>> if (ret)
>>>>> return ret;
>>>>>
>>>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>>>> +
>>>>> if (!tp->phydev) {
>>>>> mdiobus_unregister(new_bus);
>>>>> return -ENODEV;
>>>>> - } else if (!tp->phydev->drv) {
>>>>> - /* Most chip versions fail with the genphy driver.
>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>> - */
>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>> - mdiobus_unregister(new_bus);
>>>>> - return -EUNATCH;
>>>>> + } else {
>>>>> + /* tp -> phydev ok */
>>>>> + int everything_OK = 0;
>>>>> +
>>>>> + /* Check driver id versus phy */
>>>>> +
>>>>> + if (tp->phydev->drv) {
>>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>>> + u32 drv_masked = ~0;
>>>>> + u32 phydev_match = ~0;
>>>>> + u32 drv_match = 0xDEADBEEF;
>>>>> +
>>>>> + phydev_id = tp->phydev->phy_id;
>>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>>> +
>>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>>> +
>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>> + dev_debug(&pdev->dev,
>>>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>>>> + new_bus->id, phydev_id, phydev_masked,
>>>>> + phydrv_id, drv_masked);
>>>>> +#endif
>>>>> +
>>>>> + phydev_match = phydev_masked & drv_masked;
>>>>> + phydev_match = phydev_match == phydev_masked;
>>>>> +
>>>>> + drv_match = phydev_masked & drv_masked;
>>>>> + drv_match = drv_match == drv_masked;
>>>>> +
>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>>>> + new_bus->id, phydev_match, drv_match);
>>>>> +#endif
>>>>> +
>>>>> + everything_OK = (phydev_match == drv_match);
>>>>> + }
>>>>> +
>>>>> + if (!everything_OK) {
>>>>> + /* Most chip versions fail with the genphy driver.
>>>>> + * Therefore ensure that the dedicated PHY driver
>>>>> + * is loaded.
>>>>> + */
>>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>> + mdiobus_unregister(new_bus);
>>>>> + return -EUNATCH;
>>>>> + }
>>>>> }
>>>>>
>>>>> /* PHY will be woken up in rtl_open() */
>>>>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>> u64_stats_init(&tp->rx_stats.syncp);
>>>>> u64_stats_init(&tp->tx_stats.syncp);
>>>>>
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>>>> +#endif
>>>>> +
>>>>> rtl_init_mac_address(tp);
>>>>>
>>>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>>>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>> dev->hw_features |= NETIF_F_RXFCS;
>>>>>
>>>>> jumbo_max = rtl_jumbo_max(tp);
>>>>> +
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>>>> +#endif
>>>>> +
>>>>> if (jumbo_max)
>>>>> dev->max_mtu = jumbo_max;
>>>>>
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>>>> +#endif
>>>>> +
>>>>> rtl_set_irq_mask(tp);
>>>>>
>>>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>>>
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>>>> +#endif
>>>>> +
>>>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>>>> &tp->counters_phys_addr,
>>>>> GFP_KERNEL);
>>>>> if (!tp->counters)
>>>>> return -ENOMEM;
>>>>>
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>>>> +#endif
>>>>> +
>>>>> pci_set_drvdata(pdev, dev);
>>>>>
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>>>> +#endif
>>>>> +
>>>>> rc = r8169_mdio_register(tp);
>>>>> +
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>>>> +#endif
>>>>> +
>>>>> if (rc)
>>>>> return rc;
>>>>>
>>>>> /* chip gets powered up in rtl_open() */
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>>>> +#endif
>>>>> +
>>>>> rtl_pll_power_down(tp);
>>>>>
>>>>> rc = register_netdev(dev);
>>>>> +
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>>>> +#endif
>>>>> +
>>>>> if (rc)
>>>>> goto err_mdio_unregister;
>>>>>
>>>>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>> if (pci_dev_run_wake(pdev))
>>>>> pm_runtime_put_sync(&pdev->dev);
>>>>>
>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>>>> +#endif
>>>>> +
>>>>> return 0;
>>>>>
>>>>> err_mdio_unregister:
>>>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>>>> index 522760c8bca6..41777f379a57 100644
>>>>> --- a/drivers/net/phy/mdio_bus.c
>>>>> +++ b/drivers/net/phy/mdio_bus.c
>>>>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>>>> {
>>>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>>>> -
>>>>> + struct phy_device *rv = NULL;
>>>>> +/*
>>>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>>>> +*/
>>>>> if (!mdiodev)
>>>>> return NULL;
>>>>>
>>>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>>>> return NULL;
>>>>>
>>>>> - return container_of(mdiodev, struct phy_device, mdio);
>>>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>>>> +/*
>>>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>>>> + bus->id, addr, mdiodev, rv);
>>>>> +*/
>>>>> + return rv;
>>>>> }
>>>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>>>
>>>>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>>>
>>>>> bus->state = MDIOBUS_REGISTERED;
>>>>> - pr_info("%s: probed\n", bus->name);
>>>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>>>> return 0;
>>>>>
>>>>> error:
>>>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>>>> while (--i >= 0) {
>>>>> mdiodev = bus->mdio_map[i];
>>>>> if (!mdiodev)
>>>>> --
>>>>> 2.26.0
>>>>>
>>>>
>>>
>>> >From 85766c0ab77750faa4488ca7018784e3e8e9eba0 Mon Sep 17 00:00:00 2001
>>> From: Lauri Jakku <lja@iki.fi>
>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>
>>> The driver installation determination made properly by
>>> checking PHY vs DRIVER id's.
>>> ---
>>> drivers/net/ethernet/realtek/r8169_main.c | 47 +++++++++++++++++++----
>>> 1 file changed, 40 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>> index bf5bf05970a2..da08b1b1047c 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>> {
>>> struct pci_dev *pdev = tp->pci_dev;
>>> struct mii_bus *new_bus;
>>> + u32 phydev_id = 0;
>>> + u32 phydrv_id = 0;
>>> + u32 phydrv_id_mask = 0;
>>> int ret;
>>>
>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>> @@ -5172,13 +5175,43 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>> if (!tp->phydev) {
>>> mdiobus_unregister(new_bus);
>>> return -ENODEV;
>>> - } else if (!tp->phydev->drv) {
>>> - /* Most chip versions fail with the genphy driver.
>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>> - */
>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>> - mdiobus_unregister(new_bus);
>>> - return -EUNATCH;
>>> + } else {
>>> + /* tp -> phydev ok */
>>> + int everything_OK = 0;
>>> +
>>> + /* Check driver id versus phy */
>>> +
>>> + if (tp->phydev->drv) {
>>> + u32 phydev_masked = 0xBEEFDEAD;
>>> + u32 drv_masked = ~0;
>>> + u32 phydev_match = ~0;
>>> + u32 drv_match = 0xDEADBEEF;
>>> +
>>> + phydev_id = tp->phydev->phy_id;
>>> + phydrv_id = tp->phydev->drv->phy_id;
>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>> +
>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>> +
>>> + phydev_match = phydev_masked & drv_masked;
>>> + phydev_match = phydev_match == phydev_masked;
>>> +
>>> + drv_match = phydev_masked & drv_masked;
>>> + drv_match = drv_match == drv_masked;
>>> +
>>> + everything_OK = (phydev_match == drv_match);
>>> + }
>>> +
>>> + if (!everything_OK) {
>>> + /* Most chip versions fail with the genphy driver.
>>> + * Therefore ensure that the dedicated PHY driver
>>> + * is loaded.
>>> + */
>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>> + mdiobus_unregister(new_bus);
>>> + return -EUNATCH;
>>> + }
>>> }
>>>
>>> /* PHY will be woken up in rtl_open() */
>>>
>>
>>
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 15:54 ` Heiner Kallweit
@ 2020-04-13 16:10 ` Lauri Jakku
2020-04-13 16:17 ` Heiner Kallweit
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-13 16:10 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
On 13.4.2020 18.54, Heiner Kallweit wrote:
> On 13.04.2020 17:50, Lauri Jakku wrote:
>> Hi,
>>
>> On 13.4.2020 18.33, Heiner Kallweit wrote:
>>> On 13.04.2020 16:44, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> On 13.4.2020 15.18, Leon Romanovsky wrote:
>>>>> On Mon, Apr 13, 2020 at 03:01:23PM +0300, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've tought that the debug's are worth to save behind an definition/commented out, so they can be enabled if needed.
>>>>>>
>>>>>
>>>>> Please stop to do top-posting.
>>>>
>>>> I did not realise, sorry. Trying to do better.
>>>>
>>>>>
>>>>>>
>>>>>> Latest version:
>>>>>>
>>>>>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>
>>>>>> The driver installation determination made properly by
>>>>>> checking PHY vs DRIVER id's.
>>>>>> ---
>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>>>>>> drivers/net/phy/mdio_bus.c | 15 ++-
>>>>>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> index bf5bf05970a2..5e992f285527 100644
>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> @@ -61,6 +61,11 @@
>>>>>> #define R8169_MSG_DEFAULT \
>>>>>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>>>>>
>>>>>> +
>>>>>> +/*
>>>>>> +#define R8169_PROBE_DEBUG
>>>>>> +*/
>>>>>
>>>>> Of course not, it is even worse than before.
>>>>> If user recompiles module, he will add prints.
>>>>>
>>>>> Thanks
>>>>>
>>>>
>>>> New patch at the end and in attachments.
>>>>
>>> Please do as suggested and read through the kernel developer beginners
>>> guides first. The patch itself, and sending patches as attachments
>>> is not acceptable.
>>>
>>> Please provide the requested logs and information first so that we can
>>> understand your issue.
>>>
>>
>> I'm compiling newest patch + 5.6.2-2 and I'll then provide logs from
>> 5.3, 5.4 and 5.6 (without and with the patch).
>>
>> steps i take:
>> 1. power off computer properly
>> 2. take output of dmesg
>> 3. take output of ip link
>>
>> Initramfs does have libphy, realtek and r8169 modules added.
>>
> Typically you need the network driver in initramfs only when
> loading rootfs from network, e.g. via NFS.
> How is it if you remove r8169 from initramfs?
>
Hmm, I'm using Manjaro's stock packages for kernels. I removed
modules from mkinitcpio.conf and reinstall the kernel packages
now. i check do they have them installed.
One thing that I've noticed is that when doing reboot, the NIC
does not work ok after bootup. When proper power cycle is done
the NIC works ok, so something in settings etc. does not reset.
I check if adding reset to driver's probe helps, i make diffrent
patch for that.
>> This wille take some time, i try to provide the logs today.
>>
>> Do you like if they are provided in tar per configuration, or
>> how ?
>>
> The logs you can attach to the mail (name them properly).
>
>> I make the commit message have log of problem and log of solution
>> case.
>>
>>
>>>>
>>>>>> +
>>>>>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>>>>>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>>>>>> #define MC_FILTER_LIMIT 32
>>>>>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>> {
>>>>>> struct pci_dev *pdev = tp->pci_dev;
>>>>>> struct mii_bus *new_bus;
>>>>>> + u32 phydev_id = 0;
>>>>>> + u32 phydrv_id = 0;
>>>>>> + u32 phydrv_id_mask = 0;
>>>>>> int ret;
>>>>>>
>>>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>>>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>> new_bus->write = r8169_mdio_write_reg;
>>>>>>
>>>>>> ret = mdiobus_register(new_bus);
>>>>>> +
>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>> + dev_info(&pdev->dev,
>>>>>> + "mdiobus_register: %s, %d\n",
>>>>>> + new_bus->id, ret);
>>>>>> +#endif
>>>>>> if (ret)
>>>>>> return ret;
>>>>>>
>>>>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>>>>> +
>>>>>> if (!tp->phydev) {
>>>>>> mdiobus_unregister(new_bus);
>>>>>> return -ENODEV;
>>>>>> - } else if (!tp->phydev->drv) {
>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>> - */
>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>> - mdiobus_unregister(new_bus);
>>>>>> - return -EUNATCH;
>>>>>> + } else {
>>>>>> + /* tp -> phydev ok */
>>>>>> + int everything_OK = 0;
>>>>>> +
>>>>>> + /* Check driver id versus phy */
>>>>>> +
>>>>>> + if (tp->phydev->drv) {
>>>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>>>> + u32 drv_masked = ~0;
>>>>>> + u32 phydev_match = ~0;
>>>>>> + u32 drv_match = 0xDEADBEEF;
>>>>>> +
>>>>>> + phydev_id = tp->phydev->phy_id;
>>>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>>>> +
>>>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>>>> +
>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>> + dev_debug(&pdev->dev,
>>>>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>>>>> + new_bus->id, phydev_id, phydev_masked,
>>>>>> + phydrv_id, drv_masked);
>>>>>> +#endif
>>>>>> +
>>>>>> + phydev_match = phydev_masked & drv_masked;
>>>>>> + phydev_match = phydev_match == phydev_masked;
>>>>>> +
>>>>>> + drv_match = phydev_masked & drv_masked;
>>>>>> + drv_match = drv_match == drv_masked;
>>>>>> +
>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>>>>> + new_bus->id, phydev_match, drv_match);
>>>>>> +#endif
>>>>>> +
>>>>>> + everything_OK = (phydev_match == drv_match);
>>>>>> + }
>>>>>> +
>>>>>> + if (!everything_OK) {
>>>>>> + /* Most chip versions fail with the genphy driver.
>>>>>> + * Therefore ensure that the dedicated PHY driver
>>>>>> + * is loaded.
>>>>>> + */
>>>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>> + mdiobus_unregister(new_bus);
>>>>>> + return -EUNATCH;
>>>>>> + }
>>>>>> }
>>>>>>
>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>> u64_stats_init(&tp->rx_stats.syncp);
>>>>>> u64_stats_init(&tp->tx_stats.syncp);
>>>>>>
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>>>>> +#endif
>>>>>> +
>>>>>> rtl_init_mac_address(tp);
>>>>>>
>>>>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>>>>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>> dev->hw_features |= NETIF_F_RXFCS;
>>>>>>
>>>>>> jumbo_max = rtl_jumbo_max(tp);
>>>>>> +
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>>>>> +#endif
>>>>>> +
>>>>>> if (jumbo_max)
>>>>>> dev->max_mtu = jumbo_max;
>>>>>>
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>>>>> +#endif
>>>>>> +
>>>>>> rtl_set_irq_mask(tp);
>>>>>>
>>>>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>>>>
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>>>>> +#endif
>>>>>> +
>>>>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>>>>> &tp->counters_phys_addr,
>>>>>> GFP_KERNEL);
>>>>>> if (!tp->counters)
>>>>>> return -ENOMEM;
>>>>>>
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>>>>> +#endif
>>>>>> +
>>>>>> pci_set_drvdata(pdev, dev);
>>>>>>
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>>>>> +#endif
>>>>>> +
>>>>>> rc = r8169_mdio_register(tp);
>>>>>> +
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>>>>> +#endif
>>>>>> +
>>>>>> if (rc)
>>>>>> return rc;
>>>>>>
>>>>>> /* chip gets powered up in rtl_open() */
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>>>>> +#endif
>>>>>> +
>>>>>> rtl_pll_power_down(tp);
>>>>>>
>>>>>> rc = register_netdev(dev);
>>>>>> +
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>>>>> +#endif
>>>>>> +
>>>>>> if (rc)
>>>>>> goto err_mdio_unregister;
>>>>>>
>>>>>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>> if (pci_dev_run_wake(pdev))
>>>>>> pm_runtime_put_sync(&pdev->dev);
>>>>>>
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>>>>> +#endif
>>>>>> +
>>>>>> return 0;
>>>>>>
>>>>>> err_mdio_unregister:
>>>>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>>>>> index 522760c8bca6..41777f379a57 100644
>>>>>> --- a/drivers/net/phy/mdio_bus.c
>>>>>> +++ b/drivers/net/phy/mdio_bus.c
>>>>>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>>>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>>>>> {
>>>>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>>>>> -
>>>>>> + struct phy_device *rv = NULL;
>>>>>> +/*
>>>>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>>>>> +*/
>>>>>> if (!mdiodev)
>>>>>> return NULL;
>>>>>>
>>>>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>>>>> return NULL;
>>>>>>
>>>>>> - return container_of(mdiodev, struct phy_device, mdio);
>>>>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>>>>> +/*
>>>>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>>>>> + bus->id, addr, mdiodev, rv);
>>>>>> +*/
>>>>>> + return rv;
>>>>>> }
>>>>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>>>>
>>>>>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>>>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>>>>
>>>>>> bus->state = MDIOBUS_REGISTERED;
>>>>>> - pr_info("%s: probed\n", bus->name);
>>>>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>>>>> return 0;
>>>>>>
>>>>>> error:
>>>>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>>>>> while (--i >= 0) {
>>>>>> mdiodev = bus->mdio_map[i];
>>>>>> if (!mdiodev)
>>>>>> --
>>>>>> 2.26.0
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Comments inline.
>>>>>>>>
>>>>>>>> On 2020-04-13 13:58, Leon Romanovsky wrote:
>>>>>>>>> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>>>>>>>>>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>>>>>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>>>>>
>>>>>>>>>> The driver installation determination made properly by
>>>>>>>>>> checking PHY vs DRIVER id's.
>>>>>>>>>> ---
>>>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>>>>>>>>>> drivers/net/phy/mdio_bus.c | 11 +++-
>>>>>>>>>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>>>>>>>>
>>>>>>>>> I would say that most of the code is debug prints.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I tought that they are helpful to keep, they are using the debug calls, so
>>>>>>>> they are not visible if user does not like those.
>>>>>>>
>>>>>>> You are missing the point of who are your users.
>>>>>>>
>>>>>>> Users want to have working device and the code. They don't need or like
>>>>>>> to debug their kernel.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Br,
>>>>>> Lauri J.
>>>>>
>>>>>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>
>>>>>> The driver installation determination made properly by
>>>>>> checking PHY vs DRIVER id's.
>>>>>> ---
>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>>>>>> drivers/net/phy/mdio_bus.c | 15 ++-
>>>>>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> index bf5bf05970a2..5e992f285527 100644
>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> @@ -61,6 +61,11 @@
>>>>>> #define R8169_MSG_DEFAULT \
>>>>>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>>>>>
>>>>>> +
>>>>>> +/*
>>>>>> +#define R8169_PROBE_DEBUG
>>>>>> +*/
>>>>>> +
>>>>>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>>>>>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>>>>>> #define MC_FILTER_LIMIT 32
>>>>>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>> {
>>>>>> struct pci_dev *pdev = tp->pci_dev;
>>>>>> struct mii_bus *new_bus;
>>>>>> + u32 phydev_id = 0;
>>>>>> + u32 phydrv_id = 0;
>>>>>> + u32 phydrv_id_mask = 0;
>>>>>> int ret;
>>>>>>
>>>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>>>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>> new_bus->write = r8169_mdio_write_reg;
>>>>>>
>>>>>> ret = mdiobus_register(new_bus);
>>>>>> +
>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>> + dev_info(&pdev->dev,
>>>>>> + "mdiobus_register: %s, %d\n",
>>>>>> + new_bus->id, ret);
>>>>>> +#endif
>>>>>> if (ret)
>>>>>> return ret;
>>>>>>
>>>>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>>>>> +
>>>>>> if (!tp->phydev) {
>>>>>> mdiobus_unregister(new_bus);
>>>>>> return -ENODEV;
>>>>>> - } else if (!tp->phydev->drv) {
>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>> - */
>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>> - mdiobus_unregister(new_bus);
>>>>>> - return -EUNATCH;
>>>>>> + } else {
>>>>>> + /* tp -> phydev ok */
>>>>>> + int everything_OK = 0;
>>>>>> +
>>>>>> + /* Check driver id versus phy */
>>>>>> +
>>>>>> + if (tp->phydev->drv) {
>>>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>>>> + u32 drv_masked = ~0;
>>>>>> + u32 phydev_match = ~0;
>>>>>> + u32 drv_match = 0xDEADBEEF;
>>>>>> +
>>>>>> + phydev_id = tp->phydev->phy_id;
>>>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>>>> +
>>>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>>>> +
>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>> + dev_debug(&pdev->dev,
>>>>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>>>>> + new_bus->id, phydev_id, phydev_masked,
>>>>>> + phydrv_id, drv_masked);
>>>>>> +#endif
>>>>>> +
>>>>>> + phydev_match = phydev_masked & drv_masked;
>>>>>> + phydev_match = phydev_match == phydev_masked;
>>>>>> +
>>>>>> + drv_match = phydev_masked & drv_masked;
>>>>>> + drv_match = drv_match == drv_masked;
>>>>>> +
>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>>>>> + new_bus->id, phydev_match, drv_match);
>>>>>> +#endif
>>>>>> +
>>>>>> + everything_OK = (phydev_match == drv_match);
>>>>>> + }
>>>>>> +
>>>>>> + if (!everything_OK) {
>>>>>> + /* Most chip versions fail with the genphy driver.
>>>>>> + * Therefore ensure that the dedicated PHY driver
>>>>>> + * is loaded.
>>>>>> + */
>>>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>> + mdiobus_unregister(new_bus);
>>>>>> + return -EUNATCH;
>>>>>> + }
>>>>>> }
>>>>>>
>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>> u64_stats_init(&tp->rx_stats.syncp);
>>>>>> u64_stats_init(&tp->tx_stats.syncp);
>>>>>>
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>>>>> +#endif
>>>>>> +
>>>>>> rtl_init_mac_address(tp);
>>>>>>
>>>>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>>>>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>> dev->hw_features |= NETIF_F_RXFCS;
>>>>>>
>>>>>> jumbo_max = rtl_jumbo_max(tp);
>>>>>> +
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>>>>> +#endif
>>>>>> +
>>>>>> if (jumbo_max)
>>>>>> dev->max_mtu = jumbo_max;
>>>>>>
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>>>>> +#endif
>>>>>> +
>>>>>> rtl_set_irq_mask(tp);
>>>>>>
>>>>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>>>>
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>>>>> +#endif
>>>>>> +
>>>>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>>>>> &tp->counters_phys_addr,
>>>>>> GFP_KERNEL);
>>>>>> if (!tp->counters)
>>>>>> return -ENOMEM;
>>>>>>
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>>>>> +#endif
>>>>>> +
>>>>>> pci_set_drvdata(pdev, dev);
>>>>>>
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>>>>> +#endif
>>>>>> +
>>>>>> rc = r8169_mdio_register(tp);
>>>>>> +
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>>>>> +#endif
>>>>>> +
>>>>>> if (rc)
>>>>>> return rc;
>>>>>>
>>>>>> /* chip gets powered up in rtl_open() */
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>>>>> +#endif
>>>>>> +
>>>>>> rtl_pll_power_down(tp);
>>>>>>
>>>>>> rc = register_netdev(dev);
>>>>>> +
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>>>>> +#endif
>>>>>> +
>>>>>> if (rc)
>>>>>> goto err_mdio_unregister;
>>>>>>
>>>>>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>> if (pci_dev_run_wake(pdev))
>>>>>> pm_runtime_put_sync(&pdev->dev);
>>>>>>
>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>>>>> +#endif
>>>>>> +
>>>>>> return 0;
>>>>>>
>>>>>> err_mdio_unregister:
>>>>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>>>>> index 522760c8bca6..41777f379a57 100644
>>>>>> --- a/drivers/net/phy/mdio_bus.c
>>>>>> +++ b/drivers/net/phy/mdio_bus.c
>>>>>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>>>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>>>>> {
>>>>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>>>>> -
>>>>>> + struct phy_device *rv = NULL;
>>>>>> +/*
>>>>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>>>>> +*/
>>>>>> if (!mdiodev)
>>>>>> return NULL;
>>>>>>
>>>>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>>>>> return NULL;
>>>>>>
>>>>>> - return container_of(mdiodev, struct phy_device, mdio);
>>>>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>>>>> +/*
>>>>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>>>>> + bus->id, addr, mdiodev, rv);
>>>>>> +*/
>>>>>> + return rv;
>>>>>> }
>>>>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>>>>
>>>>>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>>>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>>>>
>>>>>> bus->state = MDIOBUS_REGISTERED;
>>>>>> - pr_info("%s: probed\n", bus->name);
>>>>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>>>>> return 0;
>>>>>>
>>>>>> error:
>>>>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>>>>> while (--i >= 0) {
>>>>>> mdiodev = bus->mdio_map[i];
>>>>>> if (!mdiodev)
>>>>>> --
>>>>>> 2.26.0
>>>>>>
>>>>>
>>>>
>>>> >From 85766c0ab77750faa4488ca7018784e3e8e9eba0 Mon Sep 17 00:00:00 2001
>>>> From: Lauri Jakku <lja@iki.fi>
>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>
>>>> The driver installation determination made properly by
>>>> checking PHY vs DRIVER id's.
>>>> ---
>>>> drivers/net/ethernet/realtek/r8169_main.c | 47 +++++++++++++++++++----
>>>> 1 file changed, 40 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>> index bf5bf05970a2..da08b1b1047c 100644
>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>> {
>>>> struct pci_dev *pdev = tp->pci_dev;
>>>> struct mii_bus *new_bus;
>>>> + u32 phydev_id = 0;
>>>> + u32 phydrv_id = 0;
>>>> + u32 phydrv_id_mask = 0;
>>>> int ret;
>>>>
>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>> @@ -5172,13 +5175,43 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>> if (!tp->phydev) {
>>>> mdiobus_unregister(new_bus);
>>>> return -ENODEV;
>>>> - } else if (!tp->phydev->drv) {
>>>> - /* Most chip versions fail with the genphy driver.
>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>> - */
>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>> - mdiobus_unregister(new_bus);
>>>> - return -EUNATCH;
>>>> + } else {
>>>> + /* tp -> phydev ok */
>>>> + int everything_OK = 0;
>>>> +
>>>> + /* Check driver id versus phy */
>>>> +
>>>> + if (tp->phydev->drv) {
>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>> + u32 drv_masked = ~0;
>>>> + u32 phydev_match = ~0;
>>>> + u32 drv_match = 0xDEADBEEF;
>>>> +
>>>> + phydev_id = tp->phydev->phy_id;
>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>> +
>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>> +
>>>> + phydev_match = phydev_masked & drv_masked;
>>>> + phydev_match = phydev_match == phydev_masked;
>>>> +
>>>> + drv_match = phydev_masked & drv_masked;
>>>> + drv_match = drv_match == drv_masked;
>>>> +
>>>> + everything_OK = (phydev_match == drv_match);
>>>> + }
>>>> +
>>>> + if (!everything_OK) {
>>>> + /* Most chip versions fail with the genphy driver.
>>>> + * Therefore ensure that the dedicated PHY driver
>>>> + * is loaded.
>>>> + */
>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>> + mdiobus_unregister(new_bus);
>>>> + return -EUNATCH;
>>>> + }
>>>> }
>>>>
>>>> /* PHY will be woken up in rtl_open() */
>>>>
>>>
>>>
>>
>
--
Br,
Lauri J.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 16:10 ` Lauri Jakku
@ 2020-04-13 16:17 ` Heiner Kallweit
2020-04-13 16:37 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Heiner Kallweit @ 2020-04-13 16:17 UTC (permalink / raw)
To: Lauri Jakku; +Cc: Leon Romanovsky, netdev, nic_swsd
On 13.04.2020 18:10, Lauri Jakku wrote:
>
>
> On 13.4.2020 18.54, Heiner Kallweit wrote:
>> On 13.04.2020 17:50, Lauri Jakku wrote:
>>> Hi,
>>>
>>> On 13.4.2020 18.33, Heiner Kallweit wrote:
>>>> On 13.04.2020 16:44, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>> On 13.4.2020 15.18, Leon Romanovsky wrote:
>>>>>> On Mon, Apr 13, 2020 at 03:01:23PM +0300, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've tought that the debug's are worth to save behind an definition/commented out, so they can be enabled if needed.
>>>>>>>
>>>>>>
>>>>>> Please stop to do top-posting.
>>>>>
>>>>> I did not realise, sorry. Trying to do better.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Latest version:
>>>>>>>
>>>>>>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>>
>>>>>>> The driver installation determination made properly by
>>>>>>> checking PHY vs DRIVER id's.
>>>>>>> ---
>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>>>>>>> drivers/net/phy/mdio_bus.c | 15 ++-
>>>>>>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> index bf5bf05970a2..5e992f285527 100644
>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> @@ -61,6 +61,11 @@
>>>>>>> #define R8169_MSG_DEFAULT \
>>>>>>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>>>>>>
>>>>>>> +
>>>>>>> +/*
>>>>>>> +#define R8169_PROBE_DEBUG
>>>>>>> +*/
>>>>>>
>>>>>> Of course not, it is even worse than before.
>>>>>> If user recompiles module, he will add prints.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>
>>>>> New patch at the end and in attachments.
>>>>>
>>>> Please do as suggested and read through the kernel developer beginners
>>>> guides first. The patch itself, and sending patches as attachments
>>>> is not acceptable.
>>>>
>>>> Please provide the requested logs and information first so that we can
>>>> understand your issue.
>>>>
>>>
>>> I'm compiling newest patch + 5.6.2-2 and I'll then provide logs from
>>> 5.3, 5.4 and 5.6 (without and with the patch).
>>>
>>> steps i take:
>>> 1. power off computer properly
>>> 2. take output of dmesg
>>> 3. take output of ip link
>>>
>>> Initramfs does have libphy, realtek and r8169 modules added.
>>>
>> Typically you need the network driver in initramfs only when
>> loading rootfs from network, e.g. via NFS.
>> How is it if you remove r8169 from initramfs?
>>
>
> Hmm, I'm using Manjaro's stock packages for kernels. I removed
> modules from mkinitcpio.conf and reinstall the kernel packages
> now. i check do they have them installed.
>
> One thing that I've noticed is that when doing reboot, the NIC
> does not work ok after bootup. When proper power cycle is done
> the NIC works ok, so something in settings etc. does not reset.
>
> I check if adding reset to driver's probe helps, i make diffrent
> patch for that.
>
No need for such a patch, probe is resetting the chip already.
Best provide a dmesg log of such a reboot.
The issue can also be caused by a BIOS bug, as I don't see
this behavior on my systems.
>
>>> This wille take some time, i try to provide the logs today.
>>>
>>> Do you like if they are provided in tar per configuration, or
>>> how ?
>>>
>> The logs you can attach to the mail (name them properly).
>>
>>> I make the commit message have log of problem and log of solution
>>> case.
>>>
>>>
>>>>>
>>>>>>> +
>>>>>>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>>>>>>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>>>>>>> #define MC_FILTER_LIMIT 32
>>>>>>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>> {
>>>>>>> struct pci_dev *pdev = tp->pci_dev;
>>>>>>> struct mii_bus *new_bus;
>>>>>>> + u32 phydev_id = 0;
>>>>>>> + u32 phydrv_id = 0;
>>>>>>> + u32 phydrv_id_mask = 0;
>>>>>>> int ret;
>>>>>>>
>>>>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>>>>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>> new_bus->write = r8169_mdio_write_reg;
>>>>>>>
>>>>>>> ret = mdiobus_register(new_bus);
>>>>>>> +
>>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>>> + dev_info(&pdev->dev,
>>>>>>> + "mdiobus_register: %s, %d\n",
>>>>>>> + new_bus->id, ret);
>>>>>>> +#endif
>>>>>>> if (ret)
>>>>>>> return ret;
>>>>>>>
>>>>>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>>>>>> +
>>>>>>> if (!tp->phydev) {
>>>>>>> mdiobus_unregister(new_bus);
>>>>>>> return -ENODEV;
>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>> - */
>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>> - mdiobus_unregister(new_bus);
>>>>>>> - return -EUNATCH;
>>>>>>> + } else {
>>>>>>> + /* tp -> phydev ok */
>>>>>>> + int everything_OK = 0;
>>>>>>> +
>>>>>>> + /* Check driver id versus phy */
>>>>>>> +
>>>>>>> + if (tp->phydev->drv) {
>>>>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>>>>> + u32 drv_masked = ~0;
>>>>>>> + u32 phydev_match = ~0;
>>>>>>> + u32 drv_match = 0xDEADBEEF;
>>>>>>> +
>>>>>>> + phydev_id = tp->phydev->phy_id;
>>>>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>>>>> +
>>>>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>>>>> +
>>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>>> + dev_debug(&pdev->dev,
>>>>>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>>>>>> + new_bus->id, phydev_id, phydev_masked,
>>>>>>> + phydrv_id, drv_masked);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> + phydev_match = phydev_masked & drv_masked;
>>>>>>> + phydev_match = phydev_match == phydev_masked;
>>>>>>> +
>>>>>>> + drv_match = phydev_masked & drv_masked;
>>>>>>> + drv_match = drv_match == drv_masked;
>>>>>>> +
>>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>>>>>> + new_bus->id, phydev_match, drv_match);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> + everything_OK = (phydev_match == drv_match);
>>>>>>> + }
>>>>>>> +
>>>>>>> + if (!everything_OK) {
>>>>>>> + /* Most chip versions fail with the genphy driver.
>>>>>>> + * Therefore ensure that the dedicated PHY driver
>>>>>>> + * is loaded.
>>>>>>> + */
>>>>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>> + mdiobus_unregister(new_bus);
>>>>>>> + return -EUNATCH;
>>>>>>> + }
>>>>>>> }
>>>>>>>
>>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>>> u64_stats_init(&tp->rx_stats.syncp);
>>>>>>> u64_stats_init(&tp->tx_stats.syncp);
>>>>>>>
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>>>>>> +#endif
>>>>>>> +
>>>>>>> rtl_init_mac_address(tp);
>>>>>>>
>>>>>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>>>>>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>>> dev->hw_features |= NETIF_F_RXFCS;
>>>>>>>
>>>>>>> jumbo_max = rtl_jumbo_max(tp);
>>>>>>> +
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> if (jumbo_max)
>>>>>>> dev->max_mtu = jumbo_max;
>>>>>>>
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>>>>>> +#endif
>>>>>>> +
>>>>>>> rtl_set_irq_mask(tp);
>>>>>>>
>>>>>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>>>>>
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>>>>>> &tp->counters_phys_addr,
>>>>>>> GFP_KERNEL);
>>>>>>> if (!tp->counters)
>>>>>>> return -ENOMEM;
>>>>>>>
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>>>>>> +#endif
>>>>>>> +
>>>>>>> pci_set_drvdata(pdev, dev);
>>>>>>>
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>>>>>> +#endif
>>>>>>> +
>>>>>>> rc = r8169_mdio_register(tp);
>>>>>>> +
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> if (rc)
>>>>>>> return rc;
>>>>>>>
>>>>>>> /* chip gets powered up in rtl_open() */
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>>>>>> +#endif
>>>>>>> +
>>>>>>> rtl_pll_power_down(tp);
>>>>>>>
>>>>>>> rc = register_netdev(dev);
>>>>>>> +
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> if (rc)
>>>>>>> goto err_mdio_unregister;
>>>>>>>
>>>>>>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>>> if (pci_dev_run_wake(pdev))
>>>>>>> pm_runtime_put_sync(&pdev->dev);
>>>>>>>
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>>>>>> +#endif
>>>>>>> +
>>>>>>> return 0;
>>>>>>>
>>>>>>> err_mdio_unregister:
>>>>>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>>>>>> index 522760c8bca6..41777f379a57 100644
>>>>>>> --- a/drivers/net/phy/mdio_bus.c
>>>>>>> +++ b/drivers/net/phy/mdio_bus.c
>>>>>>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>>>>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>>>>>> {
>>>>>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>>>>>> -
>>>>>>> + struct phy_device *rv = NULL;
>>>>>>> +/*
>>>>>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>>>>>> +*/
>>>>>>> if (!mdiodev)
>>>>>>> return NULL;
>>>>>>>
>>>>>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>>>>>> return NULL;
>>>>>>>
>>>>>>> - return container_of(mdiodev, struct phy_device, mdio);
>>>>>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>>>>>> +/*
>>>>>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>>>>>> + bus->id, addr, mdiodev, rv);
>>>>>>> +*/
>>>>>>> + return rv;
>>>>>>> }
>>>>>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>>>>>
>>>>>>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>>>>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>>>>>
>>>>>>> bus->state = MDIOBUS_REGISTERED;
>>>>>>> - pr_info("%s: probed\n", bus->name);
>>>>>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>>>>>> return 0;
>>>>>>>
>>>>>>> error:
>>>>>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>>>>>> while (--i >= 0) {
>>>>>>> mdiodev = bus->mdio_map[i];
>>>>>>> if (!mdiodev)
>>>>>>> --
>>>>>>> 2.26.0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Comments inline.
>>>>>>>>>
>>>>>>>>> On 2020-04-13 13:58, Leon Romanovsky wrote:
>>>>>>>>>> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>>>>>>>>>>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>>>>>>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>>>>>>
>>>>>>>>>>> The driver installation determination made properly by
>>>>>>>>>>> checking PHY vs DRIVER id's.
>>>>>>>>>>> ---
>>>>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>>>>>>>>>>> drivers/net/phy/mdio_bus.c | 11 +++-
>>>>>>>>>>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>>>>>>>>>
>>>>>>>>>> I would say that most of the code is debug prints.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I tought that they are helpful to keep, they are using the debug calls, so
>>>>>>>>> they are not visible if user does not like those.
>>>>>>>>
>>>>>>>> You are missing the point of who are your users.
>>>>>>>>
>>>>>>>> Users want to have working device and the code. They don't need or like
>>>>>>>> to debug their kernel.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Br,
>>>>>>> Lauri J.
>>>>>>
>>>>>>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>>
>>>>>>> The driver installation determination made properly by
>>>>>>> checking PHY vs DRIVER id's.
>>>>>>> ---
>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>>>>>>> drivers/net/phy/mdio_bus.c | 15 ++-
>>>>>>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> index bf5bf05970a2..5e992f285527 100644
>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> @@ -61,6 +61,11 @@
>>>>>>> #define R8169_MSG_DEFAULT \
>>>>>>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>>>>>>
>>>>>>> +
>>>>>>> +/*
>>>>>>> +#define R8169_PROBE_DEBUG
>>>>>>> +*/
>>>>>>> +
>>>>>>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>>>>>>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>>>>>>> #define MC_FILTER_LIMIT 32
>>>>>>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>> {
>>>>>>> struct pci_dev *pdev = tp->pci_dev;
>>>>>>> struct mii_bus *new_bus;
>>>>>>> + u32 phydev_id = 0;
>>>>>>> + u32 phydrv_id = 0;
>>>>>>> + u32 phydrv_id_mask = 0;
>>>>>>> int ret;
>>>>>>>
>>>>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>>>>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>> new_bus->write = r8169_mdio_write_reg;
>>>>>>>
>>>>>>> ret = mdiobus_register(new_bus);
>>>>>>> +
>>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>>> + dev_info(&pdev->dev,
>>>>>>> + "mdiobus_register: %s, %d\n",
>>>>>>> + new_bus->id, ret);
>>>>>>> +#endif
>>>>>>> if (ret)
>>>>>>> return ret;
>>>>>>>
>>>>>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>>>>>> +
>>>>>>> if (!tp->phydev) {
>>>>>>> mdiobus_unregister(new_bus);
>>>>>>> return -ENODEV;
>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>> - */
>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>> - mdiobus_unregister(new_bus);
>>>>>>> - return -EUNATCH;
>>>>>>> + } else {
>>>>>>> + /* tp -> phydev ok */
>>>>>>> + int everything_OK = 0;
>>>>>>> +
>>>>>>> + /* Check driver id versus phy */
>>>>>>> +
>>>>>>> + if (tp->phydev->drv) {
>>>>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>>>>> + u32 drv_masked = ~0;
>>>>>>> + u32 phydev_match = ~0;
>>>>>>> + u32 drv_match = 0xDEADBEEF;
>>>>>>> +
>>>>>>> + phydev_id = tp->phydev->phy_id;
>>>>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>>>>> +
>>>>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>>>>> +
>>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>>> + dev_debug(&pdev->dev,
>>>>>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>>>>>> + new_bus->id, phydev_id, phydev_masked,
>>>>>>> + phydrv_id, drv_masked);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> + phydev_match = phydev_masked & drv_masked;
>>>>>>> + phydev_match = phydev_match == phydev_masked;
>>>>>>> +
>>>>>>> + drv_match = phydev_masked & drv_masked;
>>>>>>> + drv_match = drv_match == drv_masked;
>>>>>>> +
>>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>>>>>> + new_bus->id, phydev_match, drv_match);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> + everything_OK = (phydev_match == drv_match);
>>>>>>> + }
>>>>>>> +
>>>>>>> + if (!everything_OK) {
>>>>>>> + /* Most chip versions fail with the genphy driver.
>>>>>>> + * Therefore ensure that the dedicated PHY driver
>>>>>>> + * is loaded.
>>>>>>> + */
>>>>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>> + mdiobus_unregister(new_bus);
>>>>>>> + return -EUNATCH;
>>>>>>> + }
>>>>>>> }
>>>>>>>
>>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>>> u64_stats_init(&tp->rx_stats.syncp);
>>>>>>> u64_stats_init(&tp->tx_stats.syncp);
>>>>>>>
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>>>>>> +#endif
>>>>>>> +
>>>>>>> rtl_init_mac_address(tp);
>>>>>>>
>>>>>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>>>>>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>>> dev->hw_features |= NETIF_F_RXFCS;
>>>>>>>
>>>>>>> jumbo_max = rtl_jumbo_max(tp);
>>>>>>> +
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> if (jumbo_max)
>>>>>>> dev->max_mtu = jumbo_max;
>>>>>>>
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>>>>>> +#endif
>>>>>>> +
>>>>>>> rtl_set_irq_mask(tp);
>>>>>>>
>>>>>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>>>>>
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>>>>>> &tp->counters_phys_addr,
>>>>>>> GFP_KERNEL);
>>>>>>> if (!tp->counters)
>>>>>>> return -ENOMEM;
>>>>>>>
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>>>>>> +#endif
>>>>>>> +
>>>>>>> pci_set_drvdata(pdev, dev);
>>>>>>>
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>>>>>> +#endif
>>>>>>> +
>>>>>>> rc = r8169_mdio_register(tp);
>>>>>>> +
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> if (rc)
>>>>>>> return rc;
>>>>>>>
>>>>>>> /* chip gets powered up in rtl_open() */
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>>>>>> +#endif
>>>>>>> +
>>>>>>> rtl_pll_power_down(tp);
>>>>>>>
>>>>>>> rc = register_netdev(dev);
>>>>>>> +
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> if (rc)
>>>>>>> goto err_mdio_unregister;
>>>>>>>
>>>>>>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>>> if (pci_dev_run_wake(pdev))
>>>>>>> pm_runtime_put_sync(&pdev->dev);
>>>>>>>
>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>>>>>> +#endif
>>>>>>> +
>>>>>>> return 0;
>>>>>>>
>>>>>>> err_mdio_unregister:
>>>>>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>>>>>> index 522760c8bca6..41777f379a57 100644
>>>>>>> --- a/drivers/net/phy/mdio_bus.c
>>>>>>> +++ b/drivers/net/phy/mdio_bus.c
>>>>>>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>>>>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>>>>>> {
>>>>>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>>>>>> -
>>>>>>> + struct phy_device *rv = NULL;
>>>>>>> +/*
>>>>>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>>>>>> +*/
>>>>>>> if (!mdiodev)
>>>>>>> return NULL;
>>>>>>>
>>>>>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>>>>>> return NULL;
>>>>>>>
>>>>>>> - return container_of(mdiodev, struct phy_device, mdio);
>>>>>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>>>>>> +/*
>>>>>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>>>>>> + bus->id, addr, mdiodev, rv);
>>>>>>> +*/
>>>>>>> + return rv;
>>>>>>> }
>>>>>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>>>>>
>>>>>>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>>>>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>>>>>
>>>>>>> bus->state = MDIOBUS_REGISTERED;
>>>>>>> - pr_info("%s: probed\n", bus->name);
>>>>>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>>>>>> return 0;
>>>>>>>
>>>>>>> error:
>>>>>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>>>>>> while (--i >= 0) {
>>>>>>> mdiodev = bus->mdio_map[i];
>>>>>>> if (!mdiodev)
>>>>>>> --
>>>>>>> 2.26.0
>>>>>>>
>>>>>>
>>>>>
>>>>> >From 85766c0ab77750faa4488ca7018784e3e8e9eba0 Mon Sep 17 00:00:00 2001
>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>
>>>>> The driver installation determination made properly by
>>>>> checking PHY vs DRIVER id's.
>>>>> ---
>>>>> drivers/net/ethernet/realtek/r8169_main.c | 47 +++++++++++++++++++----
>>>>> 1 file changed, 40 insertions(+), 7 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>> index bf5bf05970a2..da08b1b1047c 100644
>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>> {
>>>>> struct pci_dev *pdev = tp->pci_dev;
>>>>> struct mii_bus *new_bus;
>>>>> + u32 phydev_id = 0;
>>>>> + u32 phydrv_id = 0;
>>>>> + u32 phydrv_id_mask = 0;
>>>>> int ret;
>>>>>
>>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>>> @@ -5172,13 +5175,43 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>> if (!tp->phydev) {
>>>>> mdiobus_unregister(new_bus);
>>>>> return -ENODEV;
>>>>> - } else if (!tp->phydev->drv) {
>>>>> - /* Most chip versions fail with the genphy driver.
>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>> - */
>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>> - mdiobus_unregister(new_bus);
>>>>> - return -EUNATCH;
>>>>> + } else {
>>>>> + /* tp -> phydev ok */
>>>>> + int everything_OK = 0;
>>>>> +
>>>>> + /* Check driver id versus phy */
>>>>> +
>>>>> + if (tp->phydev->drv) {
>>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>>> + u32 drv_masked = ~0;
>>>>> + u32 phydev_match = ~0;
>>>>> + u32 drv_match = 0xDEADBEEF;
>>>>> +
>>>>> + phydev_id = tp->phydev->phy_id;
>>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>>> +
>>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>>> +
>>>>> + phydev_match = phydev_masked & drv_masked;
>>>>> + phydev_match = phydev_match == phydev_masked;
>>>>> +
>>>>> + drv_match = phydev_masked & drv_masked;
>>>>> + drv_match = drv_match == drv_masked;
>>>>> +
>>>>> + everything_OK = (phydev_match == drv_match);
>>>>> + }
>>>>> +
>>>>> + if (!everything_OK) {
>>>>> + /* Most chip versions fail with the genphy driver.
>>>>> + * Therefore ensure that the dedicated PHY driver
>>>>> + * is loaded.
>>>>> + */
>>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>> + mdiobus_unregister(new_bus);
>>>>> + return -EUNATCH;
>>>>> + }
>>>>> }
>>>>>
>>>>> /* PHY will be woken up in rtl_open() */
>>>>>
>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-13 16:17 ` Heiner Kallweit
@ 2020-04-13 16:37 ` Lauri Jakku
0 siblings, 0 replies; 57+ messages in thread
From: Lauri Jakku @ 2020-04-13 16:37 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 13.4.2020 19.17, Heiner Kallweit wrote:
> On 13.04.2020 18:10, Lauri Jakku wrote:
>>
>>
>> On 13.4.2020 18.54, Heiner Kallweit wrote:
>>> On 13.04.2020 17:50, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> On 13.4.2020 18.33, Heiner Kallweit wrote:
>>>>> On 13.04.2020 16:44, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 13.4.2020 15.18, Leon Romanovsky wrote:
>>>>>>> On Mon, Apr 13, 2020 at 03:01:23PM +0300, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I've tought that the debug's are worth to save behind an definition/commented out, so they can be enabled if needed.
>>>>>>>>
>>>>>>>
>>>>>>> Please stop to do top-posting.
>>>>>>
>>>>>> I did not realise, sorry. Trying to do better.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Latest version:
>>>>>>>>
>>>>>>>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>>>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>>>
>>>>>>>> The driver installation determination made properly by
>>>>>>>> checking PHY vs DRIVER id's.
>>>>>>>> ---
>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>>>>>>>> drivers/net/phy/mdio_bus.c | 15 ++-
>>>>>>>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>> index bf5bf05970a2..5e992f285527 100644
>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>> @@ -61,6 +61,11 @@
>>>>>>>> #define R8169_MSG_DEFAULT \
>>>>>>>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>>>>>>>
>>>>>>>> +
>>>>>>>> +/*
>>>>>>>> +#define R8169_PROBE_DEBUG
>>>>>>>> +*/
>>>>>>>
>>>>>>> Of course not, it is even worse than before.
>>>>>>> If user recompiles module, he will add prints.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>
>>>>>> New patch at the end and in attachments.
>>>>>>
>>>>> Please do as suggested and read through the kernel developer beginners
>>>>> guides first. The patch itself, and sending patches as attachments
>>>>> is not acceptable.
>>>>>
>>>>> Please provide the requested logs and information first so that we can
>>>>> understand your issue.
>>>>>
>>>>
>>>> I'm compiling newest patch + 5.6.2-2 and I'll then provide logs from
>>>> 5.3, 5.4 and 5.6 (without and with the patch).
>>>>
>>>> steps i take:
>>>> 1. power off computer properly
>>>> 2. take output of dmesg
>>>> 3. take output of ip link
>>>>
>>>> Initramfs does have libphy, realtek and r8169 modules added.
>>>>
>>> Typically you need the network driver in initramfs only when
>>> loading rootfs from network, e.g. via NFS.
>>> How is it if you remove r8169 from initramfs?
>>>
>>
>> Hmm, I'm using Manjaro's stock packages for kernels. I removed
>> modules from mkinitcpio.conf and reinstall the kernel packages
>> now. i check do they have them installed.
>>
>> One thing that I've noticed is that when doing reboot, the NIC
>> does not work ok after bootup. When proper power cycle is done
>> the NIC works ok, so something in settings etc. does not reset.
>>
>> I check if adding reset to driver's probe helps, i make diffrent
>> patch for that.
>>
> No need for such a patch, probe is resetting the chip already.
> Best provide a dmesg log of such a reboot.
> The issue can also be caused by a BIOS bug, as I don't see
> this behavior on my systems.
>
Ok, i'll do same runs with soft-reboot and power cycled ones.
Now I dont have r8169 driver in ramfs.
I'll start testing & log gathering ASAP.
>>
>>>> This wille take some time, i try to provide the logs today.
>>>>
>>>> Do you like if they are provided in tar per configuration, or
>>>> how ?
>>>>
>>> The logs you can attach to the mail (name them properly).
>>>
>>>> I make the commit message have log of problem and log of solution
>>>> case.
>>>>
>>>>
>>>>>>
>>>>>>>> +
>>>>>>>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>>>>>>>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>>>>>>>> #define MC_FILTER_LIMIT 32
>>>>>>>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>> {
>>>>>>>> struct pci_dev *pdev = tp->pci_dev;
>>>>>>>> struct mii_bus *new_bus;
>>>>>>>> + u32 phydev_id = 0;
>>>>>>>> + u32 phydrv_id = 0;
>>>>>>>> + u32 phydrv_id_mask = 0;
>>>>>>>> int ret;
>>>>>>>>
>>>>>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>>>>>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>> new_bus->write = r8169_mdio_write_reg;
>>>>>>>>
>>>>>>>> ret = mdiobus_register(new_bus);
>>>>>>>> +
>>>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>>>> + dev_info(&pdev->dev,
>>>>>>>> + "mdiobus_register: %s, %d\n",
>>>>>>>> + new_bus->id, ret);
>>>>>>>> +#endif
>>>>>>>> if (ret)
>>>>>>>> return ret;
>>>>>>>>
>>>>>>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>>>>>>> +
>>>>>>>> if (!tp->phydev) {
>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>> return -ENODEV;
>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>> - */
>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>>> - mdiobus_unregister(new_bus);
>>>>>>>> - return -EUNATCH;
>>>>>>>> + } else {
>>>>>>>> + /* tp -> phydev ok */
>>>>>>>> + int everything_OK = 0;
>>>>>>>> +
>>>>>>>> + /* Check driver id versus phy */
>>>>>>>> +
>>>>>>>> + if (tp->phydev->drv) {
>>>>>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>>>>>> + u32 drv_masked = ~0;
>>>>>>>> + u32 phydev_match = ~0;
>>>>>>>> + u32 drv_match = 0xDEADBEEF;
>>>>>>>> +
>>>>>>>> + phydev_id = tp->phydev->phy_id;
>>>>>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>>>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>>>>>> +
>>>>>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>>>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>>>>>> +
>>>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>>>> + dev_debug(&pdev->dev,
>>>>>>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>>>>>>> + new_bus->id, phydev_id, phydev_masked,
>>>>>>>> + phydrv_id, drv_masked);
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> + phydev_match = phydev_masked & drv_masked;
>>>>>>>> + phydev_match = phydev_match == phydev_masked;
>>>>>>>> +
>>>>>>>> + drv_match = phydev_masked & drv_masked;
>>>>>>>> + drv_match = drv_match == drv_masked;
>>>>>>>> +
>>>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>>>>>>> + new_bus->id, phydev_match, drv_match);
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> + everything_OK = (phydev_match == drv_match);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + if (!everything_OK) {
>>>>>>>> + /* Most chip versions fail with the genphy driver.
>>>>>>>> + * Therefore ensure that the dedicated PHY driver
>>>>>>>> + * is loaded.
>>>>>>>> + */
>>>>>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>>> + mdiobus_unregister(new_bus);
>>>>>>>> + return -EUNATCH;
>>>>>>>> + }
>>>>>>>> }
>>>>>>>>
>>>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>>>> u64_stats_init(&tp->rx_stats.syncp);
>>>>>>>> u64_stats_init(&tp->tx_stats.syncp);
>>>>>>>>
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> rtl_init_mac_address(tp);
>>>>>>>>
>>>>>>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>>>>>>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>>>> dev->hw_features |= NETIF_F_RXFCS;
>>>>>>>>
>>>>>>>> jumbo_max = rtl_jumbo_max(tp);
>>>>>>>> +
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> if (jumbo_max)
>>>>>>>> dev->max_mtu = jumbo_max;
>>>>>>>>
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> rtl_set_irq_mask(tp);
>>>>>>>>
>>>>>>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>>>>>>
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>>>>>>> &tp->counters_phys_addr,
>>>>>>>> GFP_KERNEL);
>>>>>>>> if (!tp->counters)
>>>>>>>> return -ENOMEM;
>>>>>>>>
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> pci_set_drvdata(pdev, dev);
>>>>>>>>
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> rc = r8169_mdio_register(tp);
>>>>>>>> +
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> if (rc)
>>>>>>>> return rc;
>>>>>>>>
>>>>>>>> /* chip gets powered up in rtl_open() */
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> rtl_pll_power_down(tp);
>>>>>>>>
>>>>>>>> rc = register_netdev(dev);
>>>>>>>> +
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> if (rc)
>>>>>>>> goto err_mdio_unregister;
>>>>>>>>
>>>>>>>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>>>> if (pci_dev_run_wake(pdev))
>>>>>>>> pm_runtime_put_sync(&pdev->dev);
>>>>>>>>
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> return 0;
>>>>>>>>
>>>>>>>> err_mdio_unregister:
>>>>>>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>>>>>>> index 522760c8bca6..41777f379a57 100644
>>>>>>>> --- a/drivers/net/phy/mdio_bus.c
>>>>>>>> +++ b/drivers/net/phy/mdio_bus.c
>>>>>>>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>>>>>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>>>>>>> {
>>>>>>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>>>>>>> -
>>>>>>>> + struct phy_device *rv = NULL;
>>>>>>>> +/*
>>>>>>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>>>>>>> +*/
>>>>>>>> if (!mdiodev)
>>>>>>>> return NULL;
>>>>>>>>
>>>>>>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>>>>>>> return NULL;
>>>>>>>>
>>>>>>>> - return container_of(mdiodev, struct phy_device, mdio);
>>>>>>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>>>>>>> +/*
>>>>>>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>>>>>>> + bus->id, addr, mdiodev, rv);
>>>>>>>> +*/
>>>>>>>> + return rv;
>>>>>>>> }
>>>>>>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>>>>>>
>>>>>>>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>>>>>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>>>>>>
>>>>>>>> bus->state = MDIOBUS_REGISTERED;
>>>>>>>> - pr_info("%s: probed\n", bus->name);
>>>>>>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>>>>>>> return 0;
>>>>>>>>
>>>>>>>> error:
>>>>>>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>>>>>>> while (--i >= 0) {
>>>>>>>> mdiodev = bus->mdio_map[i];
>>>>>>>> if (!mdiodev)
>>>>>>>> --
>>>>>>>> 2.26.0
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Comments inline.
>>>>>>>>>>
>>>>>>>>>> On 2020-04-13 13:58, Leon Romanovsky wrote:
>>>>>>>>>>> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>>>>>>>>>>>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
>>>>>>>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>>>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>>>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>>>>>>>
>>>>>>>>>>>> The driver installation determination made properly by
>>>>>>>>>>>> checking PHY vs DRIVER id's.
>>>>>>>>>>>> ---
>>>>>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
>>>>>>>>>>>> drivers/net/phy/mdio_bus.c | 11 +++-
>>>>>>>>>>>> 2 files changed, 72 insertions(+), 9 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> I would say that most of the code is debug prints.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I tought that they are helpful to keep, they are using the debug calls, so
>>>>>>>>>> they are not visible if user does not like those.
>>>>>>>>>
>>>>>>>>> You are missing the point of who are your users.
>>>>>>>>>
>>>>>>>>> Users want to have working device and the code. They don't need or like
>>>>>>>>> to debug their kernel.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Br,
>>>>>>>> Lauri J.
>>>>>>>
>>>>>>>> From 1a75f6f9065a58180de1fa3c48fd80418af6c347 Mon Sep 17 00:00:00 2001
>>>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>>>
>>>>>>>> The driver installation determination made properly by
>>>>>>>> checking PHY vs DRIVER id's.
>>>>>>>> ---
>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 114 ++++++++++++++++++++--
>>>>>>>> drivers/net/phy/mdio_bus.c | 15 ++-
>>>>>>>> 2 files changed, 119 insertions(+), 10 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>> index bf5bf05970a2..5e992f285527 100644
>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>> @@ -61,6 +61,11 @@
>>>>>>>> #define R8169_MSG_DEFAULT \
>>>>>>>> (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
>>>>>>>>
>>>>>>>> +
>>>>>>>> +/*
>>>>>>>> +#define R8169_PROBE_DEBUG
>>>>>>>> +*/
>>>>>>>> +
>>>>>>>> /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>>>>>>>> The RTL chips use a 64 element hash table based on the Ethernet CRC. */
>>>>>>>> #define MC_FILTER_LIMIT 32
>>>>>>>> @@ -5149,6 +5154,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>> {
>>>>>>>> struct pci_dev *pdev = tp->pci_dev;
>>>>>>>> struct mii_bus *new_bus;
>>>>>>>> + u32 phydev_id = 0;
>>>>>>>> + u32 phydrv_id = 0;
>>>>>>>> + u32 phydrv_id_mask = 0;
>>>>>>>> int ret;
>>>>>>>>
>>>>>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>>>>>> @@ -5165,20 +5173,69 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>> new_bus->write = r8169_mdio_write_reg;
>>>>>>>>
>>>>>>>> ret = mdiobus_register(new_bus);
>>>>>>>> +
>>>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>>>> + dev_info(&pdev->dev,
>>>>>>>> + "mdiobus_register: %s, %d\n",
>>>>>>>> + new_bus->id, ret);
>>>>>>>> +#endif
>>>>>>>> if (ret)
>>>>>>>> return ret;
>>>>>>>>
>>>>>>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>>>>>>> +
>>>>>>>> if (!tp->phydev) {
>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>> return -ENODEV;
>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>> - */
>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>>> - mdiobus_unregister(new_bus);
>>>>>>>> - return -EUNATCH;
>>>>>>>> + } else {
>>>>>>>> + /* tp -> phydev ok */
>>>>>>>> + int everything_OK = 0;
>>>>>>>> +
>>>>>>>> + /* Check driver id versus phy */
>>>>>>>> +
>>>>>>>> + if (tp->phydev->drv) {
>>>>>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>>>>>> + u32 drv_masked = ~0;
>>>>>>>> + u32 phydev_match = ~0;
>>>>>>>> + u32 drv_match = 0xDEADBEEF;
>>>>>>>> +
>>>>>>>> + phydev_id = tp->phydev->phy_id;
>>>>>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>>>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>>>>>> +
>>>>>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>>>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>>>>>> +
>>>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>>>> + dev_debug(&pdev->dev,
>>>>>>>> + "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
>>>>>>>> + new_bus->id, phydev_id, phydev_masked,
>>>>>>>> + phydrv_id, drv_masked);
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> + phydev_match = phydev_masked & drv_masked;
>>>>>>>> + phydev_match = phydev_match == phydev_masked;
>>>>>>>> +
>>>>>>>> + drv_match = phydev_masked & drv_masked;
>>>>>>>> + drv_match = drv_match == drv_masked;
>>>>>>>> +
>>>>>>>> +#ifdef R8169_PROBE_DEBUG
>>>>>>>> + dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
>>>>>>>> + new_bus->id, phydev_match, drv_match);
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> + everything_OK = (phydev_match == drv_match);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + if (!everything_OK) {
>>>>>>>> + /* Most chip versions fail with the genphy driver.
>>>>>>>> + * Therefore ensure that the dedicated PHY driver
>>>>>>>> + * is loaded.
>>>>>>>> + */
>>>>>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>>> + mdiobus_unregister(new_bus);
>>>>>>>> + return -EUNATCH;
>>>>>>>> + }
>>>>>>>> }
>>>>>>>>
>>>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>>> @@ -5435,6 +5492,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>>>> u64_stats_init(&tp->rx_stats.syncp);
>>>>>>>> u64_stats_init(&tp->tx_stats.syncp);
>>>>>>>>
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: MAC\n");
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> rtl_init_mac_address(tp);
>>>>>>>>
>>>>>>>> dev->ethtool_ops = &rtl8169_ethtool_ops;
>>>>>>>> @@ -5483,29 +5544,64 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>>>> dev->hw_features |= NETIF_F_RXFCS;
>>>>>>>>
>>>>>>>> jumbo_max = rtl_jumbo_max(tp);
>>>>>>>> +
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> if (jumbo_max)
>>>>>>>> dev->max_mtu = jumbo_max;
>>>>>>>>
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: irq mask\n");
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> rtl_set_irq_mask(tp);
>>>>>>>>
>>>>>>>> tp->fw_name = rtl_chip_infos[chipset].fw_name;
>>>>>>>>
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
>>>>>>>> &tp->counters_phys_addr,
>>>>>>>> GFP_KERNEL);
>>>>>>>> if (!tp->counters)
>>>>>>>> return -ENOMEM;
>>>>>>>>
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: set driver data\n");
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> pci_set_drvdata(pdev, dev);
>>>>>>>>
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: register mdio\n");
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> rc = r8169_mdio_register(tp);
>>>>>>>> +
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> if (rc)
>>>>>>>> return rc;
>>>>>>>>
>>>>>>>> /* chip gets powered up in rtl_open() */
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: pll pwr down\n");
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> rtl_pll_power_down(tp);
>>>>>>>>
>>>>>>>> rc = register_netdev(dev);
>>>>>>>> +
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> if (rc)
>>>>>>>> goto err_mdio_unregister;
>>>>>>>>
>>>>>>>> @@ -5525,6 +5621,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>>>> if (pci_dev_run_wake(pdev))
>>>>>>>> pm_runtime_put_sync(&pdev->dev);
>>>>>>>>
>>>>>>>> +#ifdef R816X_PROBE_DEBUG
>>>>>>>> + dev_dbg(&pdev->dev, "init: ALL DONE!\n");
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> return 0;
>>>>>>>>
>>>>>>>> err_mdio_unregister:
>>>>>>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>>>>>>> index 522760c8bca6..41777f379a57 100644
>>>>>>>> --- a/drivers/net/phy/mdio_bus.c
>>>>>>>> +++ b/drivers/net/phy/mdio_bus.c
>>>>>>>> @@ -112,14 +112,22 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
>>>>>>>> struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
>>>>>>>> {
>>>>>>>> struct mdio_device *mdiodev = bus->mdio_map[addr];
>>>>>>>> -
>>>>>>>> + struct phy_device *rv = NULL;
>>>>>>>> +/*
>>>>>>>> + pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
>>>>>>>> +*/
>>>>>>>> if (!mdiodev)
>>>>>>>> return NULL;
>>>>>>>>
>>>>>>>> if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
>>>>>>>> return NULL;
>>>>>>>>
>>>>>>>> - return container_of(mdiodev, struct phy_device, mdio);
>>>>>>>> + rv = container_of(mdiodev, struct phy_device, mdio);
>>>>>>>> +/*
>>>>>>>> + pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
>>>>>>>> + bus->id, addr, mdiodev, rv);
>>>>>>>> +*/
>>>>>>>> + return rv;
>>>>>>>> }
>>>>>>>> EXPORT_SYMBOL(mdiobus_get_phy);
>>>>>>>>
>>>>>>>> @@ -645,10 +653,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
>>>>>>>> mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
>>>>>>>>
>>>>>>>> bus->state = MDIOBUS_REGISTERED;
>>>>>>>> - pr_info("%s: probed\n", bus->name);
>>>>>>>> + pr_info("%s: probed (mdiobus_register)\n", bus->name);
>>>>>>>> return 0;
>>>>>>>>
>>>>>>>> error:
>>>>>>>> + pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
>>>>>>>> while (--i >= 0) {
>>>>>>>> mdiodev = bus->mdio_map[i];
>>>>>>>> if (!mdiodev)
>>>>>>>> --
>>>>>>>> 2.26.0
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> >From 85766c0ab77750faa4488ca7018784e3e8e9eba0 Mon Sep 17 00:00:00 2001
>>>>>> From: Lauri Jakku <lja@iki.fi>
>>>>>> Date: Mon, 13 Apr 2020 13:18:35 +0300
>>>>>> Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>
>>>>>> The driver installation determination made properly by
>>>>>> checking PHY vs DRIVER id's.
>>>>>> ---
>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 47 +++++++++++++++++++----
>>>>>> 1 file changed, 40 insertions(+), 7 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> index bf5bf05970a2..da08b1b1047c 100644
>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> @@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>> {
>>>>>> struct pci_dev *pdev = tp->pci_dev;
>>>>>> struct mii_bus *new_bus;
>>>>>> + u32 phydev_id = 0;
>>>>>> + u32 phydrv_id = 0;
>>>>>> + u32 phydrv_id_mask = 0;
>>>>>> int ret;
>>>>>>
>>>>>> new_bus = devm_mdiobus_alloc(&pdev->dev);
>>>>>> @@ -5172,13 +5175,43 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>> if (!tp->phydev) {
>>>>>> mdiobus_unregister(new_bus);
>>>>>> return -ENODEV;
>>>>>> - } else if (!tp->phydev->drv) {
>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>> - */
>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>> - mdiobus_unregister(new_bus);
>>>>>> - return -EUNATCH;
>>>>>> + } else {
>>>>>> + /* tp -> phydev ok */
>>>>>> + int everything_OK = 0;
>>>>>> +
>>>>>> + /* Check driver id versus phy */
>>>>>> +
>>>>>> + if (tp->phydev->drv) {
>>>>>> + u32 phydev_masked = 0xBEEFDEAD;
>>>>>> + u32 drv_masked = ~0;
>>>>>> + u32 phydev_match = ~0;
>>>>>> + u32 drv_match = 0xDEADBEEF;
>>>>>> +
>>>>>> + phydev_id = tp->phydev->phy_id;
>>>>>> + phydrv_id = tp->phydev->drv->phy_id;
>>>>>> + phydrv_id_mask = tp->phydev->drv->phy_id_mask;
>>>>>> +
>>>>>> + drv_masked = phydrv_id & phydrv_id_mask;
>>>>>> + phydev_masked = phydev_id & phydrv_id_mask;
>>>>>> +
>>>>>> + phydev_match = phydev_masked & drv_masked;
>>>>>> + phydev_match = phydev_match == phydev_masked;
>>>>>> +
>>>>>> + drv_match = phydev_masked & drv_masked;
>>>>>> + drv_match = drv_match == drv_masked;
>>>>>> +
>>>>>> + everything_OK = (phydev_match == drv_match);
>>>>>> + }
>>>>>> +
>>>>>> + if (!everything_OK) {
>>>>>> + /* Most chip versions fail with the genphy driver.
>>>>>> + * Therefore ensure that the dedicated PHY driver
>>>>>> + * is loaded.
>>>>>> + */
>>>>>> + dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>> + mdiobus_unregister(new_bus);
>>>>>> + return -EUNATCH;
>>>>>> + }
>>>>>> }
>>>>>>
>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
--
Br,
Lauri J.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
[not found] ` <d3adc7f2-06bb-45bc-ab02-3d443999cefd@gmail.com>
@ 2020-04-15 16:18 ` Heiner Kallweit
[not found] ` <4860e57e-93e4-24f5-6103-fa80acbdfa0d@pp.inet.fi>
2021-03-11 16:00 ` gmail
0 siblings, 2 replies; 57+ messages in thread
From: Heiner Kallweit @ 2020-04-15 16:18 UTC (permalink / raw)
To: Lauri Jakku; +Cc: Leon Romanovsky, netdev, nic_swsd
On 15.04.2020 16:39, Lauri Jakku wrote:
> Hi,
>
> There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
There's no point in working on your patch. W/o proper justification it
isn't acceptable anyway. And so far we still don't know which problem
you actually have.
FIRST please provide the requested logs and explain the actual problem
(incl. the commit that caused the regression).
> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti:
>
> Hi,
>
> Fair enough, i'll strip them.
>
> -lja
>
> On 2020-04-13 14:34, Leon Romanovsky wrote:
>
> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote:
>
> Hi,
>
> Comments inline.
>
> On 2020-04-13 13:58, Leon Romanovsky wrote:
>
> On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>
> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
> From: Lauri Jakku <lja@iki.fi>
> Date: Mon, 13 Apr 2020 13:18:35 +0300
> Subject: [PATCH] NET: r8168/r8169 identifying fix
>
> The driver installation determination made properly by
> checking PHY vs DRIVER id's.
> ---
> drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
> drivers/net/phy/mdio_bus.c | 11 +++-
> 2 files changed, 72 insertions(+), 9 deletions(-)
>
>
> I would say that most of the code is debug prints.
>
>
>
> I tought that they are helpful to keep, they are using the debug calls, so
> they are not visible if user does not like those.
>
>
> You are missing the point of who are your users.
>
> Users want to have working device and the code. They don't need or like
> to debug their kernel.
>
> Thanks
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
[not found] ` <4860e57e-93e4-24f5-6103-fa80acbdfa0d@pp.inet.fi>
@ 2020-04-16 18:26 ` Heiner Kallweit
2020-04-16 18:37 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Heiner Kallweit @ 2020-04-16 18:26 UTC (permalink / raw)
To: Lauri Jakku; +Cc: Leon Romanovsky, netdev, nic_swsd
On 16.04.2020 13:30, Lauri Jakku wrote:
> Hi,
>
>
> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>
> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>
> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>
> All different initcpio's have realtek.ko in them.
>
Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
a random number as PHY ID, resulting in no PHY driver being found.
Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>
> The problem with old method seems to be, that device does not have had time to attach before the
> PHY driver check.
>
> The patch:
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index bf5bf05970a2..acd122a88d4a 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> if (!tp->phydev) {
> mdiobus_unregister(new_bus);
> return -ENODEV;
> - } else if (!tp->phydev->drv) {
> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
> /* Most chip versions fail with the genphy driver.
> * Therefore ensure that the dedicated PHY driver is loaded.
> */
> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> + dev_err(&pdev->dev, "Not known MAC version.\n");
> mdiobus_unregister(new_bus);
> return -EUNATCH;
> }
> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
> index 66b8c61ca74c..aba2b304b821 100644
> --- a/drivers/net/phy/phy-core.c
> +++ b/drivers/net/phy/phy-core.c
> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>
> static int __phy_read_page(struct phy_device *phydev)
> {
> + /* If not attached, do nothing (no warning) */
> + if (!phydev->attached_dev)
> + return -EOPNOTSUPP;
> +
> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
> return -EOPNOTSUPP;
>
> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device *phydev)
>
> static int __phy_write_page(struct phy_device *phydev, int page)
> {
> + /* If not attached, do nothing (no warning) */
> + if (!phydev->attached_dev)
> + return -EOPNOTSUPP;
> +
> if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
> return -EOPNOTSUPP;
>
> return phydev->drv->write_page(phydev, page);
> }
>
> +
> /**
> * phy_save_page() - take the bus lock and save the current page
> * @phydev: a pointer to a &struct phy_device
>
>
>
> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>
> On 15.04.2020 16:39, Lauri Jakku wrote:
>
> Hi, There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
>
>
> There's no point in working on your patch. W/o proper justification it
> isn't acceptable anyway. And so far we still don't know which problem
> you actually have.
> FIRST please provide the requested logs and explain the actual problem
> (incl. the commit that caused the regression).
>
>
>
>
> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>
> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver installation determination made properly by checking PHY vs DRIVER id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files changed, 72 insertions(+), 9 deletions(-) I would say that most of the code is debug prints. I tought that they are helpful to keep, they are using the debug calls, so they are not visible if user does not like those. You are missing the point of who are your users. Users want to have working device and the code. They don't need or like to debug their kernel. Thanks
>
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-16 18:26 ` Heiner Kallweit
@ 2020-04-16 18:37 ` Lauri Jakku
2020-04-16 19:58 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-16 18:37 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 16.4.2020 21.26, Heiner Kallweit wrote:
> On 16.04.2020 13:30, Lauri Jakku wrote:
>> Hi,
>>
>>
>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>
>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>
>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>
>> All different initcpio's have realtek.ko in them.
>>
> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
> a random number as PHY ID, resulting in no PHY driver being found.
> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>
OK, I try that, thank you :)
>> The problem with old method seems to be, that device does not have had time to attach before the
>> PHY driver check.
>>
>> The patch:
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index bf5bf05970a2..acd122a88d4a 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>> /* Most chip versions fail with the genphy driver.
>> * Therefore ensure that the dedicated PHY driver is loaded.
>> */
>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>> mdiobus_unregister(new_bus);
>> return -EUNATCH;
>> }
>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>> index 66b8c61ca74c..aba2b304b821 100644
>> --- a/drivers/net/phy/phy-core.c
>> +++ b/drivers/net/phy/phy-core.c
>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>
>> static int __phy_read_page(struct phy_device *phydev)
>> {
>> + /* If not attached, do nothing (no warning) */
>> + if (!phydev->attached_dev)
>> + return -EOPNOTSUPP;
>> +
>> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>> return -EOPNOTSUPP;
>>
>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device *phydev)
>>
>> static int __phy_write_page(struct phy_device *phydev, int page)
>> {
>> + /* If not attached, do nothing (no warning) */
>> + if (!phydev->attached_dev)
>> + return -EOPNOTSUPP;
>> +
>> if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>> return -EOPNOTSUPP;
>>
>> return phydev->drv->write_page(phydev, page);
>> }
>>
>> +
>> /**
>> * phy_save_page() - take the bus lock and save the current page
>> * @phydev: a pointer to a &struct phy_device
>>
>>
>>
>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>
>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>
>> Hi, There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
>>
>>
>> There's no point in working on your patch. W/o proper justification it
>> isn't acceptable anyway. And so far we still don't know which problem
>> you actually have.
>> FIRST please provide the requested logs and explain the actual problem
>> (incl. the commit that caused the regression).
>>
>>
>>
>>
>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>>
>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver installation determination made properly by checking PHY vs DRIVER id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files changed, 72 insertions(+), 9 deletions(-) I would say that most of the code is debug prints. I tought that they are helpful to keep, they are using the debug calls, so they are not visible if user does not like those. You are missing the point of who are your users. Users want to have working device and the code. They don't need or like to debug their kernel. Thanks
>>
>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-16 18:37 ` Lauri Jakku
@ 2020-04-16 19:58 ` Lauri Jakku
2020-04-16 20:02 ` Heiner Kallweit
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-16 19:58 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 16.4.2020 21.37, Lauri Jakku wrote:
> Hi,
>
> On 16.4.2020 21.26, Heiner Kallweit wrote:
>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>> Hi,
>>>
>>>
>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications -->
>>> network does not work
>>>
>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods
>>> only) --> network does not work
>>>
>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods ->
>>> devices show up ok, network works
>>>
>>> All different initcpio's have realtek.ko in them.
>>>
>> Thanks for the logs. Based on the logs you're presumable affected by
>> a known BIOS bug.
>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>> In the first referenced tickets it's about the same mainboard (with
>> earlier BIOS version).
>> BIOS on this mainboard seems to not initialize the network chip / PHY
>> correctly, it reports
>> a random number as PHY ID, resulting in no PHY driver being found.
>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be
>> gone.
>>
> OK, I try that, thank you :)
>
It seems that i DO have the ROM's enabled, i'm now testing some mutex
guard for phy state and try to use it as indicator
that attach has been done. One thing i've noticed is that driver needs
to be reloaded to allow traffic (ie. ping works etc.)
>>> The problem with old method seems to be, that device does not have
>>> had time to attach before the
>>> PHY driver check.
>>>
>>> The patch:
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>> index bf5bf05970a2..acd122a88d4a 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct
>>> rtl8169_private *tp)
>>> if (!tp->phydev) {
>>> mdiobus_unregister(new_bus);
>>> return -ENODEV;
>>> - } else if (!tp->phydev->drv) {
>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>> /* Most chip versions fail with the genphy driver.
>>> * Therefore ensure that the dedicated PHY driver
>>> is loaded.
>>> */
>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it
>>> needs to be added to initramfs?\n");
>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>> mdiobus_unregister(new_bus);
>>> return -EUNATCH;
>>> }
>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>> index 66b8c61ca74c..aba2b304b821 100644
>>> --- a/drivers/net/phy/phy-core.c
>>> +++ b/drivers/net/phy/phy-core.c
>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>> static int __phy_read_page(struct phy_device *phydev)
>>> {
>>> + /* If not attached, do nothing (no warning) */
>>> + if (!phydev->attached_dev)
>>> + return -EOPNOTSUPP;
>>> +
>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback
>>> not available, PHY driver not loaded?\n"))
>>> return -EOPNOTSUPP;
>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device
>>> *phydev)
>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>> {
>>> + /* If not attached, do nothing (no warning) */
>>> + if (!phydev->attached_dev)
>>> + return -EOPNOTSUPP;
>>> +
>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page
>>> callback not available, PHY driver not loaded?\n"))
>>> return -EOPNOTSUPP;
>>> return phydev->drv->write_page(phydev, page);
>>> }
>>> +
>>> /**
>>> * phy_save_page() - take the bus lock and save the current page
>>> * @phydev: a pointer to a &struct phy_device
>>>
>>>
>>>
>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com
>>> <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>
>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>
>>> Hi, There seems to he Something odd problem, maybe timing
>>> related. Stripped version not workingas expected. I get back to you,
>>> when i have it working.
>>>
>>>
>>> There's no point in working on your patch. W/o proper
>>> justification it
>>> isn't acceptable anyway. And so far we still don't know which
>>> problem
>>> you actually have.
>>> FIRST please provide the requested logs and explain the actual
>>> problem
>>> (incl. the commit that caused the regression).
>>>
>>>
>>>
>>>
>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com
>>> <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip
>>> them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>
>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku
>>> wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky
>>> wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote:
>>> From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
>>> 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35
>>> +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver
>>> installation determination made properly by checking PHY vs DRIVER
>>> id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70
>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files
>>> changed, 72 insertions(+), 9 deletions(-) I would say that most of
>>> the code is debug prints. I tought that they are helpful to keep,
>>> they are using the debug calls, so they are not visible if user does
>>> not like those. You are missing the point of who are your users.
>>> Users want to have working device and the code. They don't need or
>>> like to debug their kernel. Thanks
>>>
>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-16 19:58 ` Lauri Jakku
@ 2020-04-16 20:02 ` Heiner Kallweit
2020-04-16 20:10 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Heiner Kallweit @ 2020-04-16 20:02 UTC (permalink / raw)
To: Lauri Jakku; +Cc: Leon Romanovsky, netdev, nic_swsd
On 16.04.2020 21:58, Lauri Jakku wrote:
> Hi,
>
> On 16.4.2020 21.37, Lauri Jakku wrote:
>> Hi,
>>
>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>>
>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>
>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>
>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>
>>>> All different initcpio's have realtek.ko in them.
>>>>
>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>> a random number as PHY ID, resulting in no PHY driver being found.
>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>
>> OK, I try that, thank you :)
>>
>
> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>
> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>
All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
And what do you mean with "it seems"? Is the option enabled or not?
>
>>>> The problem with old method seems to be, that device does not have had time to attach before the
>>>> PHY driver check.
>>>>
>>>> The patch:
>>>>
>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>> if (!tp->phydev) {
>>>> mdiobus_unregister(new_bus);
>>>> return -ENODEV;
>>>> - } else if (!tp->phydev->drv) {
>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>> /* Most chip versions fail with the genphy driver.
>>>> * Therefore ensure that the dedicated PHY driver is loaded.
>>>> */
>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>> mdiobus_unregister(new_bus);
>>>> return -EUNATCH;
>>>> }
>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>> --- a/drivers/net/phy/phy-core.c
>>>> +++ b/drivers/net/phy/phy-core.c
>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>> static int __phy_read_page(struct phy_device *phydev)
>>>> {
>>>> + /* If not attached, do nothing (no warning) */
>>>> + if (!phydev->attached_dev)
>>>> + return -EOPNOTSUPP;
>>>> +
>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>>> return -EOPNOTSUPP;
>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device *phydev)
>>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>>> {
>>>> + /* If not attached, do nothing (no warning) */
>>>> + if (!phydev->attached_dev)
>>>> + return -EOPNOTSUPP;
>>>> +
>>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>>> return -EOPNOTSUPP;
>>>> return phydev->drv->write_page(phydev, page);
>>>> }
>>>> +
>>>> /**
>>>> * phy_save_page() - take the bus lock and save the current page
>>>> * @phydev: a pointer to a &struct phy_device
>>>>
>>>>
>>>>
>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>
>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>
>>>> Hi, There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
>>>>
>>>>
>>>> There's no point in working on your patch. W/o proper justification it
>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>> you actually have.
>>>> FIRST please provide the requested logs and explain the actual problem
>>>> (incl. the commit that caused the regression).
>>>>
>>>>
>>>>
>>>>
>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>
>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver installation determination made properly by checking PHY vs DRIVER id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files changed, 72 insertions(+), 9 deletions(-) I would say that most of the code is debug prints. I tought that they are helpful to keep, they are using the debug calls, so they are not visible if user does not like those. You are missing the point of who are your users. Users want to have working device and the code. They don't need or like to debug their kernel. Thanks
>>>>
>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-16 20:02 ` Heiner Kallweit
@ 2020-04-16 20:10 ` Lauri Jakku
2020-04-16 20:38 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-16 20:10 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
On 16.4.2020 23.02, Heiner Kallweit wrote:
> On 16.04.2020 21:58, Lauri Jakku wrote:
>> Hi,
>>
>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>> Hi,
>>>
>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>>
>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>>
>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>>
>>>>> All different initcpio's have realtek.ko in them.
>>>>>
>>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>>
>>> OK, I try that, thank you :)
>>>
>> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>>
>> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>
> All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
> And what do you mean with "it seems"? Is the option enabled or not?
>
I do have ROM's enabled, and it does not help with my issue.
>>>>> The problem with old method seems to be, that device does not have had time to attach before the
>>>>> PHY driver check.
>>>>>
>>>>> The patch:
>>>>>
>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>> if (!tp->phydev) {
>>>>> mdiobus_unregister(new_bus);
>>>>> return -ENODEV;
>>>>> - } else if (!tp->phydev->drv) {
>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>> /* Most chip versions fail with the genphy driver.
>>>>> * Therefore ensure that the dedicated PHY driver is loaded.
>>>>> */
>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>> mdiobus_unregister(new_bus);
>>>>> return -EUNATCH;
>>>>> }
>>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>> --- a/drivers/net/phy/phy-core.c
>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>> {
>>>>> + /* If not attached, do nothing (no warning) */
>>>>> + if (!phydev->attached_dev)
>>>>> + return -EOPNOTSUPP;
>>>>> +
>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>>>> return -EOPNOTSUPP;
>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device *phydev)
>>>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>>>> {
>>>>> + /* If not attached, do nothing (no warning) */
>>>>> + if (!phydev->attached_dev)
>>>>> + return -EOPNOTSUPP;
>>>>> +
>>>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>>>> return -EOPNOTSUPP;
>>>>> return phydev->drv->write_page(phydev, page);
>>>>> }
>>>>> +
>>>>> /**
>>>>> * phy_save_page() - take the bus lock and save the current page
>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>
>>>>>
>>>>>
>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>
>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>
>>>>> Hi, There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
>>>>>
>>>>>
>>>>> There's no point in working on your patch. W/o proper justification it
>>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>>> you actually have.
>>>>> FIRST please provide the requested logs and explain the actual problem
>>>>> (incl. the commit that caused the regression).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>
>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver installation determination made properly by checking PHY vs DRIVER id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files changed, 72 insertions(+), 9 deletions(-) I would say that most of the code is debug prints. I tought that they are helpful to keep, they are using the debug calls, so they are not visible if user does not like those. You are missing the point of who are your users. Users want to have working device and the code. They don't need or like to debug their kernel. Thanks
>>>>>
>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-16 20:10 ` Lauri Jakku
@ 2020-04-16 20:38 ` Lauri Jakku
2020-04-16 20:50 ` Heiner Kallweit
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-16 20:38 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi
On 16.4.2020 23.10, Lauri Jakku wrote:
>
> On 16.4.2020 23.02, Heiner Kallweit wrote:
>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>> Hi,
>>>
>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications -->
>>>>>> network does not work
>>>>>>
>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods
>>>>>> only) --> network does not work
>>>>>>
>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods ->
>>>>>> devices show up ok, network works
>>>>>>
>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>
>>>>> Thanks for the logs. Based on the logs you're presumable affected
>>>>> by a known BIOS bug.
>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>> In the first referenced tickets it's about the same mainboard
>>>>> (with earlier BIOS version).
>>>>> BIOS on this mainboard seems to not initialize the network chip /
>>>>> PHY correctly, it reports
>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should
>>>>> be gone.
>>>>>
>>>> OK, I try that, thank you :)
>>>>
>>> It seems that i DO have the ROM's enabled, i'm now testing some
>>> mutex guard for phy state and try to use it as indicator
>>>
>>> that attach has been done. One thing i've noticed is that driver
>>> needs to be reloaded to allow traffic (ie. ping works etc.)
>>>
>> All that shouldn't be needed. Just check with which PHY ID the PHY
>> comes up.
>> And what do you mean with "it seems"? Is the option enabled or not?
>>
> I do have ROM's enabled, and it does not help with my issue.
I check the ID, and revert all other changes, and check how it is
working after adding the PHY id to list.
>>>>>> The problem with old method seems to be, that device does not
>>>>>> have had time to attach before the
>>>>>> PHY driver check.
>>>>>>
>>>>>> The patch:
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct
>>>>>> rtl8169_private *tp)
>>>>>> if (!tp->phydev) {
>>>>>> mdiobus_unregister(new_bus);
>>>>>> return -ENODEV;
>>>>>> - } else if (!tp->phydev->drv) {
>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>> /* Most chip versions fail with the genphy driver.
>>>>>> * Therefore ensure that the dedicated PHY
>>>>>> driver is loaded.
>>>>>> */
>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe
>>>>>> it needs to be added to initramfs?\n");
>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>> mdiobus_unregister(new_bus);
>>>>>> return -EUNATCH;
>>>>>> }
>>>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>> {
>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>> + if (!phydev->attached_dev)
>>>>>> + return -EOPNOTSUPP;
>>>>>> +
>>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page
>>>>>> callback not available, PHY driver not loaded?\n"))
>>>>>> return -EOPNOTSUPP;
>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct
>>>>>> phy_device *phydev)
>>>>>> static int __phy_write_page(struct phy_device *phydev, int
>>>>>> page)
>>>>>> {
>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>> + if (!phydev->attached_dev)
>>>>>> + return -EOPNOTSUPP;
>>>>>> +
>>>>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page
>>>>>> callback not available, PHY driver not loaded?\n"))
>>>>>> return -EOPNOTSUPP;
>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>> }
>>>>>> +
>>>>>> /**
>>>>>> * phy_save_page() - take the bus lock and save the current page
>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>
>>>>>>
>>>>>>
>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com
>>>>>> <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>
>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>
>>>>>> Hi, There seems to he Something odd problem, maybe
>>>>>> timing related. Stripped version not workingas expected. I get
>>>>>> back to you, when i have it working.
>>>>>>
>>>>>>
>>>>>> There's no point in working on your patch. W/o proper
>>>>>> justification it
>>>>>> isn't acceptable anyway. And so far we still don't know
>>>>>> which problem
>>>>>> you actually have.
>>>>>> FIRST please provide the requested logs and explain the
>>>>>> actual problem
>>>>>> (incl. the commit that caused the regression).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku
>>>>>> <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi,
>>>>>> Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon
>>>>>> Romanovsky wrote:
>>>>>>
>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku
>>>>>> wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky
>>>>>> wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku
>>>>>> wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17
>>>>>> 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr
>>>>>> 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying
>>>>>> fix The driver installation determination made properly by
>>>>>> checking PHY vs DRIVER id's. ---
>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70
>>>>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2
>>>>>> files changed, 72 insertions(+), 9 deletions(-) I would say that
>>>>>> most of the code is debug prints. I tought that they are helpful
>>>>>> to keep, they are using the debug calls, so they are not visible
>>>>>> if user does not like those. You are missing the point of who are
>>>>>> your users. Users want to have working device and the code. They
>>>>>> don't need or like to debug their kernel. Thanks
>>>>>>
>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-16 20:38 ` Lauri Jakku
@ 2020-04-16 20:50 ` Heiner Kallweit
2020-04-17 6:23 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Heiner Kallweit @ 2020-04-16 20:50 UTC (permalink / raw)
To: Lauri Jakku; +Cc: Leon Romanovsky, netdev, nic_swsd
On 16.04.2020 22:38, Lauri Jakku wrote:
> Hi
>
> On 16.4.2020 23.10, Lauri Jakku wrote:
>>
>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>>>>
>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>>>>
>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>>>>
>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>
>>>>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>>>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>>>>
>>>>> OK, I try that, thank you :)
>>>>>
>>>> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>>>>
>>>> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>
>>> All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>
>> I do have ROM's enabled, and it does not help with my issue.
>
Your BIOS is a beta version, downgrading to F7 may help. Then you have the same
mainboard + BIOS as the user who opened bug ticket 202275.
> I check the ID, and revert all other changes, and check how it is working after adding the PHY id to list.
>
>>>>>>> The problem with old method seems to be, that device does not have had time to attach before the
>>>>>>> PHY driver check.
>>>>>>>
>>>>>>> The patch:
>>>>>>>
>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>> if (!tp->phydev) {
>>>>>>> mdiobus_unregister(new_bus);
>>>>>>> return -ENODEV;
>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>> /* Most chip versions fail with the genphy driver.
>>>>>>> * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>> */
>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>> mdiobus_unregister(new_bus);
>>>>>>> return -EUNATCH;
>>>>>>> }
>>>>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>> {
>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>> + if (!phydev->attached_dev)
>>>>>>> + return -EOPNOTSUPP;
>>>>>>> +
>>>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>>>>>> return -EOPNOTSUPP;
>>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device *phydev)
>>>>>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>>>>>> {
>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>> + if (!phydev->attached_dev)
>>>>>>> + return -EOPNOTSUPP;
>>>>>>> +
>>>>>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>>>>>> return -EOPNOTSUPP;
>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>> }
>>>>>>> +
>>>>>>> /**
>>>>>>> * phy_save_page() - take the bus lock and save the current page
>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>
>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>
>>>>>>> Hi, There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
>>>>>>>
>>>>>>>
>>>>>>> There's no point in working on your patch. W/o proper justification it
>>>>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>>>>> you actually have.
>>>>>>> FIRST please provide the requested logs and explain the actual problem
>>>>>>> (incl. the commit that caused the regression).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>
>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver installation determination made properly by checking PHY vs DRIVER id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files changed, 72 insertions(+), 9 deletions(-) I would say that most of the code is debug prints. I tought that they are helpful to keep, they are using the debug calls, so they are not visible if user does not like those. You are missing the point of who are your users. Users want to have working device and the code. They don't need or like to debug their kernel. Thanks
>>>>>>>
>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-16 20:50 ` Heiner Kallweit
@ 2020-04-17 6:23 ` Lauri Jakku
2020-04-17 7:30 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-17 6:23 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
On 16.4.2020 23.50, Heiner Kallweit wrote:
> On 16.04.2020 22:38, Lauri Jakku wrote:
>> Hi
>>
>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>>>>>
>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>>>>>
>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>>>>>
>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>
>>>>>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>>>>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>>>>>
>>>>>> OK, I try that, thank you :)
>>>>>>
>>>>> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>>>>>
>>>>> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>
>>>> All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>
>>> I do have ROM's enabled, and it does not help with my issue.
> Your BIOS is a beta version, downgrading to F7 may help. Then you have the same
> mainboard + BIOS as the user who opened bug ticket 202275.
>
huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
version: 0xc2077002
huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: MAC
version: 23
....
huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
version: 0x1cc912
huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC
version: 23
.. after module unload & load cycle:
huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
version: 0x1cc912
huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC
version: 23
it seem to be the case that the phy_id chances onetime, then stays the
same. I'll do few shutdowns and see
is there a pattern at all .. next i'm going to try how it behaves, if i
read mac/phy versions twice on MAC version 23.
The BIOS downgrade: I'd like to solve this without downgrading BIOS. If
I can't, then I'll do systemd-service that
reloads r8169 driver at boot, cause then network is just fine.
>> I check the ID, and revert all other changes, and check how it is working after adding the PHY id to list.
>>
>>>>>>>> The problem with old method seems to be, that device does not have had time to attach before the
>>>>>>>> PHY driver check.
>>>>>>>>
>>>>>>>> The patch:
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>> if (!tp->phydev) {
>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>> return -ENODEV;
>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>> /* Most chip versions fail with the genphy driver.
>>>>>>>> * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>> */
>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>> return -EUNATCH;
>>>>>>>> }
>>>>>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>>> {
>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>> +
>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>>>>>>> return -EOPNOTSUPP;
>>>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device *phydev)
>>>>>>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>>>>>>> {
>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>> +
>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>>>>>>> return -EOPNOTSUPP;
>>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>>> }
>>>>>>>> +
>>>>>>>> /**
>>>>>>>> * phy_save_page() - take the bus lock and save the current page
>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>>
>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>
>>>>>>>> Hi, There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
>>>>>>>>
>>>>>>>>
>>>>>>>> There's no point in working on your patch. W/o proper justification it
>>>>>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>>>>>> you actually have.
>>>>>>>> FIRST please provide the requested logs and explain the actual problem
>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>
>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver installation determination made properly by checking PHY vs DRIVER id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files changed, 72 insertions(+), 9 deletions(-) I would say that most of the code is debug prints. I tought that they are helpful to keep, they are using the debug calls, so they are not visible if user does not like those. You are missing the point of who are your users. Users want to have working device and the code. They don't need or like to debug their kernel. Thanks
>>>>>>>>
>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-17 6:23 ` Lauri Jakku
@ 2020-04-17 7:30 ` Lauri Jakku
2020-04-17 8:57 ` Heiner Kallweit
2020-04-18 11:06 ` Lauri Jakku
0 siblings, 2 replies; 57+ messages in thread
From: Lauri Jakku @ 2020-04-17 7:30 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 17.4.2020 9.23, Lauri Jakku wrote:
>
> On 16.4.2020 23.50, Heiner Kallweit wrote:
>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>> Hi
>>>
>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications
>>>>>>>>> --> network does not work
>>>>>>>>>
>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169
>>>>>>>>> mods only) --> network does not work
>>>>>>>>>
>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods
>>>>>>>>> -> devices show up ok, network works
>>>>>>>>>
>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>
>>>>>>>> Thanks for the logs. Based on the logs you're presumable
>>>>>>>> affected by a known BIOS bug.
>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>> In the first referenced tickets it's about the same mainboard
>>>>>>>> (with earlier BIOS version).
>>>>>>>> BIOS on this mainboard seems to not initialize the network chip
>>>>>>>> / PHY correctly, it reports
>>>>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem
>>>>>>>> should be gone.
>>>>>>>>
>>>>>>> OK, I try that, thank you :)
>>>>>>>
>>>>>> It seems that i DO have the ROM's enabled, i'm now testing some
>>>>>> mutex guard for phy state and try to use it as indicator
>>>>>>
>>>>>> that attach has been done. One thing i've noticed is that driver
>>>>>> needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>>
>>>>> All that shouldn't be needed. Just check with which PHY ID the PHY
>>>>> comes up.
>>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>>
>>>> I do have ROM's enabled, and it does not help with my issue.
>> Your BIOS is a beta version, downgrading to F7 may help. Then you
>> have the same
>> mainboard + BIOS as the user who opened bug ticket 202275.
>>
> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
> version: 0xc2077002
> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: MAC
> version: 23
>
> ....
>
> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
> version: 0x1cc912
>
> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC
> version: 23
>
> .. after module unload & load cycle:
>
> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
> version: 0x1cc912
> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC
> version: 23
>
>
> it seem to be the case that the phy_id chances onetime, then stays the
> same. I'll do few shutdowns and see
>
> is there a pattern at all .. next i'm going to try how it behaves, if
> i read mac/phy versions twice on MAC version 23.
>
>
> The BIOS downgrade: I'd like to solve this without downgrading BIOS.
> If I can't, then I'll do systemd-service that
>
> reloads r8169 driver at boot, cause then network is just fine.
>
>
What i've gathered samples now, there is three values for PHY ID:
[sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep "PHY ver"
huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
version: 0xc2077002
huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
version: 0xc2077002
huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
version: 0x1cc912
huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
version: 0x1cc912
huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
version: 0x1cc912
huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
version: 0x1cc912
huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
version: 0xc1071002
huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
version: 0xc1071002
huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
version: 0x1cc912
huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
version: 0x1cc912
huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
version: 0xc1071002
huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
version: 0xc1071002
huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
version: 0x1cc912
huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
version: 0x1cc912
huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
version: 0xc1071002
huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
version: 0xc1071002
huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
version: 0x1cc912
huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
version: 0x1cc912
I dont know are those hard coded or what, and are they device specific
how much.
i haven't coldbooted things up, that may be that something to check do
they vary how per coldboot.
>>> I check the ID, and revert all other changes, and check how it is
>>> working after adding the PHY id to list.
>>>
>>>>>>>>> The problem with old method seems to be, that device does not
>>>>>>>>> have had time to attach before the
>>>>>>>>> PHY driver check.
>>>>>>>>>
>>>>>>>>> The patch:
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct
>>>>>>>>> rtl8169_private *tp)
>>>>>>>>> if (!tp->phydev) {
>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>> return -ENODEV;
>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>> /* Most chip versions fail with the genphy
>>>>>>>>> driver.
>>>>>>>>> * Therefore ensure that the dedicated PHY
>>>>>>>>> driver is loaded.
>>>>>>>>> */
>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded,
>>>>>>>>> maybe it needs to be added to initramfs?\n");
>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>> return -EUNATCH;
>>>>>>>>> }
>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c
>>>>>>>>> b/drivers/net/phy/phy-core.c
>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>> {
>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>> +
>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page
>>>>>>>>> callback not available, PHY driver not loaded?\n"))
>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct
>>>>>>>>> phy_device *phydev)
>>>>>>>>> static int __phy_write_page(struct phy_device *phydev,
>>>>>>>>> int page)
>>>>>>>>> {
>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>> +
>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page
>>>>>>>>> callback not available, PHY driver not loaded?\n"))
>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>>>> }
>>>>>>>>> +
>>>>>>>>> /**
>>>>>>>>> * phy_save_page() - take the bus lock and save the
>>>>>>>>> current page
>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com
>>>>>>>>> <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>>>
>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>
>>>>>>>>> Hi, There seems to he Something odd problem, maybe
>>>>>>>>> timing related. Stripped version not workingas expected. I get
>>>>>>>>> back to you, when i have it working.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There's no point in working on your patch. W/o proper
>>>>>>>>> justification it
>>>>>>>>> isn't acceptable anyway. And so far we still don't know
>>>>>>>>> which problem
>>>>>>>>> you actually have.
>>>>>>>>> FIRST please provide the requested logs and explain the
>>>>>>>>> actual problem
>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku
>>>>>>>>> <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti:
>>>>>>>>> Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34,
>>>>>>>>> Leon Romanovsky wrote:
>>>>>>>>>
>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri
>>>>>>>>> Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon
>>>>>>>>> Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300,
>>>>>>>>> Lauri Jakku wrote: From
>>>>>>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
>>>>>>>>> 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020
>>>>>>>>> 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying
>>>>>>>>> fix The driver installation determination made properly by
>>>>>>>>> checking PHY vs DRIVER id's. ---
>>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70
>>>>>>>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2
>>>>>>>>> files changed, 72 insertions(+), 9 deletions(-) I would say
>>>>>>>>> that most of the code is debug prints. I tought that they are
>>>>>>>>> helpful to keep, they are using the debug calls, so they are
>>>>>>>>> not visible if user does not like those. You are missing the
>>>>>>>>> point of who are your users. Users want to have working device
>>>>>>>>> and the code. They don't need or like to debug their kernel.
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-17 7:30 ` Lauri Jakku
@ 2020-04-17 8:57 ` Heiner Kallweit
2020-04-18 11:06 ` Lauri Jakku
1 sibling, 0 replies; 57+ messages in thread
From: Heiner Kallweit @ 2020-04-17 8:57 UTC (permalink / raw)
To: Lauri Jakku; +Cc: Leon Romanovsky, netdev, nic_swsd
On 17.04.2020 09:30, Lauri Jakku wrote:
> Hi,
>
> On 17.4.2020 9.23, Lauri Jakku wrote:
>>
>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>> Hi
>>>>
>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>>>>>>>
>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>>>>>>>
>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>>>>>>>
>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>
>>>>>>>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>>>>>>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>>>>>>>
>>>>>>>> OK, I try that, thank you :)
>>>>>>>>
>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>>>>>>>
>>>>>>> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>>>
>>>>>> All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
>>>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>>>
>>>>> I do have ROM's enabled, and it does not help with my issue.
>>> Your BIOS is a beta version, downgrading to F7 may help. Then you have the same
>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>
>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: MAC version: 23
>>
>> ....
>>
>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>
>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>
>> .. after module unload & load cycle:
>>
>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>
>>
>> it seem to be the case that the phy_id chances onetime, then stays the same. I'll do few shutdowns and see
>>
>> is there a pattern at all .. next i'm going to try how it behaves, if i read mac/phy versions twice on MAC version 23.
>>
>>
>> The BIOS downgrade: I'd like to solve this without downgrading BIOS. If I can't, then I'll do systemd-service that
>>
>> reloads r8169 driver at boot, cause then network is just fine.
>>
>>
> What i've gathered samples now, there is three values for PHY ID:
>
> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep "PHY ver"
> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc2077002
> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>
> I dont know are those hard coded or what, and are they device specific how much.
>
0x001cc912 is the correct value, the other ones are more or less random values
caused by the BIOS bug.
> i haven't coldbooted things up, that may be that something to check do they vary how per coldboot.
>
>>>> I check the ID, and revert all other changes, and check how it is working after adding the PHY id to list.
>>>>
>>>>>>>>>> The problem with old method seems to be, that device does not have had time to attach before the
>>>>>>>>>> PHY driver check.
>>>>>>>>>>
>>>>>>>>>> The patch:
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>> return -ENODEV;
>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>> /* Most chip versions fail with the genphy driver.
>>>>>>>>>> * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>>>> */
>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>> return -EUNATCH;
>>>>>>>>>> }
>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>> {
>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>> +
>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>>>>>>>>> {
>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>> +
>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>>>>> }
>>>>>>>>>> +
>>>>>>>>>> /**
>>>>>>>>>> * phy_save_page() - take the bus lock and save the current page
>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>>>>
>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>
>>>>>>>>>> Hi, There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There's no point in working on your patch. W/o proper justification it
>>>>>>>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>>>>>>>> you actually have.
>>>>>>>>>> FIRST please provide the requested logs and explain the actual problem
>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver installation determination made properly by checking PHY vs DRIVER id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files changed, 72 insertions(+), 9 deletions(-) I would say that most of the code is debug prints. I tought that they are helpful to keep, they are using the debug calls, so they are not visible if user does not like those. You are missing the point of who are your users. Users want to have working device and the code. They don't need or like to debug their kernel. Thanks
>>>>>>>>>>
>>>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-17 7:30 ` Lauri Jakku
2020-04-17 8:57 ` Heiner Kallweit
@ 2020-04-18 11:06 ` Lauri Jakku
2020-04-18 18:46 ` Lauri Jakku
1 sibling, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-18 11:06 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
[-- Attachment #1: Type: text/plain, Size: 11497 bytes --]
Hi,
On 17.4.2020 10.30, Lauri Jakku wrote:
> Hi,
>
> On 17.4.2020 9.23, Lauri Jakku wrote:
>>
>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>> Hi
>>>>
>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications
>>>>>>>>>> --> network does not work
>>>>>>>>>>
>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169
>>>>>>>>>> mods only) --> network does not work
>>>>>>>>>>
>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169
>>>>>>>>>> mods -> devices show up ok, network works
>>>>>>>>>>
>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>
>>>>>>>>> Thanks for the logs. Based on the logs you're presumable
>>>>>>>>> affected by a known BIOS bug.
>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>> In the first referenced tickets it's about the same mainboard
>>>>>>>>> (with earlier BIOS version).
>>>>>>>>> BIOS on this mainboard seems to not initialize the network
>>>>>>>>> chip / PHY correctly, it reports
>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being
>>>>>>>>> found.
>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem
>>>>>>>>> should be gone.
>>>>>>>>>
>>>>>>>> OK, I try that, thank you :)
>>>>>>>>
>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing some
>>>>>>> mutex guard for phy state and try to use it as indicator
>>>>>>>
>>>>>>> that attach has been done. One thing i've noticed is that driver
>>>>>>> needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>>>
>>>>>> All that shouldn't be needed. Just check with which PHY ID the
>>>>>> PHY comes up.
>>>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>>>
>>>>> I do have ROM's enabled, and it does not help with my issue.
>>> Your BIOS is a beta version, downgrading to F7 may help. Then you
>>> have the same
>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>
>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
>> version: 0xc2077002
>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: MAC
>> version: 23
>>
>> ....
>>
>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
>> version: 0x1cc912
>>
>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC
>> version: 23
>>
>> .. after module unload & load cycle:
>>
>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
>> version: 0x1cc912
>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC
>> version: 23
>>
>>
>> it seem to be the case that the phy_id chances onetime, then stays
>> the same. I'll do few shutdowns and see
>>
>> is there a pattern at all .. next i'm going to try how it behaves, if
>> i read mac/phy versions twice on MAC version 23.
>>
>>
>> The BIOS downgrade: I'd like to solve this without downgrading BIOS.
>> If I can't, then I'll do systemd-service that
>>
>> reloads r8169 driver at boot, cause then network is just fine.
>>
>>
> What i've gathered samples now, there is three values for PHY ID:
>
> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep "PHY
> ver"
> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
> version: 0xc2077002
> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
> version: 0xc2077002
> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
> version: 0x1cc912
> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
> version: 0x1cc912
> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
> version: 0x1cc912
> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
> version: 0x1cc912
> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
> version: 0xc1071002
> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
> version: 0xc1071002
> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
> version: 0x1cc912
> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
> version: 0x1cc912
> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
> version: 0xc1071002
> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
> version: 0xc1071002
> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
> version: 0x1cc912
> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
> version: 0x1cc912
> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
> version: 0xc1071002
> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
> version: 0xc1071002
> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
> version: 0x1cc912
> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
> version: 0x1cc912
>
> I dont know are those hard coded or what, and are they device specific
> how much.
>
> i haven't coldbooted things up, that may be that something to check do
> they vary how per coldboot.
>
>>>> I check the ID, and revert all other changes, and check how it is
>>>> working after adding the PHY id to list.
>>>>
What i've now learned: the patch + script + journald services -> Results
working network, but it is still a workaround.
>>>>>>>>>> The problem with old method seems to be, that device does not
>>>>>>>>>> have had time to attach before the
>>>>>>>>>> PHY driver check.
>>>>>>>>>>
>>>>>>>>>> The patch:
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct
>>>>>>>>>> rtl8169_private *tp)
>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>> return -ENODEV;
>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>> /* Most chip versions fail with the genphy
>>>>>>>>>> driver.
>>>>>>>>>> * Therefore ensure that the dedicated PHY
>>>>>>>>>> driver is loaded.
>>>>>>>>>> */
>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded,
>>>>>>>>>> maybe it needs to be added to initramfs?\n");
>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>> return -EUNATCH;
>>>>>>>>>> }
>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c
>>>>>>>>>> b/drivers/net/phy/phy-core.c
>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>> {
>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>> +
>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page
>>>>>>>>>> callback not available, PHY driver not loaded?\n"))
>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct
>>>>>>>>>> phy_device *phydev)
>>>>>>>>>> static int __phy_write_page(struct phy_device *phydev,
>>>>>>>>>> int page)
>>>>>>>>>> {
>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>> +
>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page,
>>>>>>>>>> "write_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>>>>> }
>>>>>>>>>> +
>>>>>>>>>> /**
>>>>>>>>>> * phy_save_page() - take the bus lock and save the
>>>>>>>>>> current page
>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit
>>>>>>>>>> <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>>>>
>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>
>>>>>>>>>> Hi, There seems to he Something odd problem, maybe
>>>>>>>>>> timing related. Stripped version not workingas expected. I
>>>>>>>>>> get back to you, when i have it working.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There's no point in working on your patch. W/o proper
>>>>>>>>>> justification it
>>>>>>>>>> isn't acceptable anyway. And so far we still don't
>>>>>>>>>> know which problem
>>>>>>>>>> you actually have.
>>>>>>>>>> FIRST please provide the requested logs and explain
>>>>>>>>>> the actual problem
>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku
>>>>>>>>>> <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti:
>>>>>>>>>> Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34,
>>>>>>>>>> Leon Romanovsky wrote:
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri
>>>>>>>>>> Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon
>>>>>>>>>> Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300,
>>>>>>>>>> Lauri Jakku wrote: From
>>>>>>>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
>>>>>>>>>> 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020
>>>>>>>>>> 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying
>>>>>>>>>> fix The driver installation determination made properly by
>>>>>>>>>> checking PHY vs DRIVER id's. ---
>>>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70
>>>>>>>>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++-
>>>>>>>>>> 2 files changed, 72 insertions(+), 9 deletions(-) I would say
>>>>>>>>>> that most of the code is debug prints. I tought that they are
>>>>>>>>>> helpful to keep, they are using the debug calls, so they are
>>>>>>>>>> not visible if user does not like those. You are missing the
>>>>>>>>>> point of who are your users. Users want to have working
>>>>>>>>>> device and the code. They don't need or like to debug their
>>>>>>>>>> kernel. Thanks
>>>>>>>>>>
>>>>>>>>>>
[-- Attachment #2: refresh-network.service --]
[-- Type: text/x-dbus-service, Size: 546 bytes --]
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Refresh network
After=refresh-network.target
Before=multi-user.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/refresh-network.sh
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
[-- Attachment #3: refresh-network.target --]
[-- Type: text/x-systemd-unit, Size: 523 bytes --]
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Refresh network
After=network.target refresh-network.service
Before=multi-user.target
Requires=network.target
[Install]
WantedBy=refresh-network.service multi-user.target
[-- Attachment #4: refresh-network.sh --]
[-- Type: application/x-shellscript, Size: 459 bytes --]
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-18 11:06 ` Lauri Jakku
@ 2020-04-18 18:46 ` Lauri Jakku
2020-04-19 15:09 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-18 18:46 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 18.4.2020 14.06, Lauri Jakku wrote:
> Hi,
>
> On 17.4.2020 10.30, Lauri Jakku wrote:
>> Hi,
>>
>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>
>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>> Hi
>>>>>
>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications
>>>>>>>>>>> --> network does not work
>>>>>>>>>>>
>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169
>>>>>>>>>>> mods only) --> network does not work
>>>>>>>>>>>
>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169
>>>>>>>>>>> mods -> devices show up ok, network works
>>>>>>>>>>>
>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>
>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable
>>>>>>>>>> affected by a known BIOS bug.
>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>> In the first referenced tickets it's about the same mainboard
>>>>>>>>>> (with earlier BIOS version).
>>>>>>>>>> BIOS on this mainboard seems to not initialize the network
>>>>>>>>>> chip / PHY correctly, it reports
>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being
>>>>>>>>>> found.
>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem
>>>>>>>>>> should be gone.
>>>>>>>>>>
>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>
>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing some
>>>>>>>> mutex guard for phy state and try to use it as indicator
>>>>>>>>
>>>>>>>> that attach has been done. One thing i've noticed is that
>>>>>>>> driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>>>>
>>>>>>> All that shouldn't be needed. Just check with which PHY ID the
>>>>>>> PHY comes up.
>>>>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>>>>
>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>> Your BIOS is a beta version, downgrading to F7 may help. Then you
>>>> have the same
>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>
>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>> PHY version: 0xc2077002
>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>> MAC version: 23
>>>
>>> ....
>>>
>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> PHY version: 0x1cc912
>>>
>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> MAC version: 23
>>>
>>> .. after module unload & load cycle:
>>>
>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> PHY version: 0x1cc912
>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> MAC version: 23
>>>
>>>
>>> it seem to be the case that the phy_id chances onetime, then stays
>>> the same. I'll do few shutdowns and see
>>>
>>> is there a pattern at all .. next i'm going to try how it behaves,
>>> if i read mac/phy versions twice on MAC version 23.
>>>
>>>
>>> The BIOS downgrade: I'd like to solve this without downgrading BIOS.
>>> If I can't, then I'll do systemd-service that
>>>
>>> reloads r8169 driver at boot, cause then network is just fine.
>>>
>>>
>> What i've gathered samples now, there is three values for PHY ID:
>>
>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep "PHY
>> ver"
>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
>> version: 0xc2077002
>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
>> version: 0xc2077002
>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
>> version: 0x1cc912
>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
>> version: 0x1cc912
>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
>> version: 0x1cc912
>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
>> version: 0x1cc912
>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
>> version: 0xc1071002
>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
>> version: 0xc1071002
>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
>> version: 0x1cc912
>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
>> version: 0x1cc912
>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
>> version: 0xc1071002
>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
>> version: 0xc1071002
>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
>> version: 0x1cc912
>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
>> version: 0x1cc912
>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
>> version: 0xc1071002
>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
>> version: 0xc1071002
>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY
>> version: 0x1cc912
>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY
>> version: 0x1cc912
>>
>> I dont know are those hard coded or what, and are they device
>> specific how much.
>>
>> i haven't coldbooted things up, that may be that something to check
>> do they vary how per coldboot.
>>
>>>>> I check the ID, and revert all other changes, and check how it is
>>>>> working after adding the PHY id to list.
>>>>>
> What i've now learned: the patch + script + journald services ->
> Results working network, but it is still a workaround.
>
Following patch trusts the MAC version, another thing witch could help
is to derive method to do 2dn pass of the probeing:
if specific MAC version is found.
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index acd122a88d4a..62b37a1abc24 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct
rtl8169_private *tp)
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "Not known MAC version.\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ dev_info(&pdev->dev, "PHY version: 0x%x\n",
tp->phydev->phy_id);
+ dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
+
+ if (tp->mac_version == RTL_GIGA_MAC_NONE) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY
driver is loaded.
+ */
+ dev_err(&pdev->dev, "Not known MAC/PHY
version.\n", tp->phydev->phy_id);
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
>
>>>>>>>>>>> The problem with old method seems to be, that device does
>>>>>>>>>>> not have had time to attach before the
>>>>>>>>>>> PHY driver check.
>>>>>>>>>>>
>>>>>>>>>>> The patch:
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int
>>>>>>>>>>> r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>> /* Most chip versions fail with the
>>>>>>>>>>> genphy driver.
>>>>>>>>>>> * Therefore ensure that the dedicated
>>>>>>>>>>> PHY driver is loaded.
>>>>>>>>>>> */
>>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded,
>>>>>>>>>>> maybe it needs to be added to initramfs?\n");
>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC
>>>>>>>>>>> version.\n");
>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>> return -EUNATCH;
>>>>>>>>>>> }
>>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c
>>>>>>>>>>> b/drivers/net/phy/phy-core.c
>>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>> {
>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>> +
>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page
>>>>>>>>>>> callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct
>>>>>>>>>>> phy_device *phydev)
>>>>>>>>>>> static int __phy_write_page(struct phy_device *phydev,
>>>>>>>>>>> int page)
>>>>>>>>>>> {
>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>> +
>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page,
>>>>>>>>>>> "write_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>>>>>> }
>>>>>>>>>>> +
>>>>>>>>>>> /**
>>>>>>>>>>> * phy_save_page() - take the bus lock and save the
>>>>>>>>>>> current page
>>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit
>>>>>>>>>>> <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>>>>>
>>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi, There seems to he Something odd problem,
>>>>>>>>>>> maybe timing related. Stripped version not workingas
>>>>>>>>>>> expected. I get back to you, when i have it working.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> There's no point in working on your patch. W/o proper
>>>>>>>>>>> justification it
>>>>>>>>>>> isn't acceptable anyway. And so far we still don't
>>>>>>>>>>> know which problem
>>>>>>>>>>> you actually have.
>>>>>>>>>>> FIRST please provide the requested logs and explain
>>>>>>>>>>> the actual problem
>>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku
>>>>>>>>>>> <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti:
>>>>>>>>>>> Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34,
>>>>>>>>>>> Leon Romanovsky wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri
>>>>>>>>>>> Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon
>>>>>>>>>>> Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300,
>>>>>>>>>>> Lauri Jakku wrote: From
>>>>>>>>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
>>>>>>>>>>> 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020
>>>>>>>>>>> 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying
>>>>>>>>>>> fix The driver installation determination made properly by
>>>>>>>>>>> checking PHY vs DRIVER id's. ---
>>>>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70
>>>>>>>>>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++-
>>>>>>>>>>> 2 files changed, 72 insertions(+), 9 deletions(-) I would
>>>>>>>>>>> say that most of the code is debug prints. I tought that
>>>>>>>>>>> they are helpful to keep, they are using the debug calls, so
>>>>>>>>>>> they are not visible if user does not like those. You are
>>>>>>>>>>> missing the point of who are your users. Users want to have
>>>>>>>>>>> working device and the code. They don't need or like to
>>>>>>>>>>> debug their kernel. Thanks
>>>>>>>>>>>
>>>>>>>>>>>
^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-18 18:46 ` Lauri Jakku
@ 2020-04-19 15:09 ` Lauri Jakku
2020-04-19 16:49 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-19 15:09 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 18.4.2020 21.46, Lauri Jakku wrote:
> Hi,
>
> On 18.4.2020 14.06, Lauri Jakku wrote:
>> Hi,
>>
>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>> Hi,
>>>
>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>
>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>> Hi
>>>>>>
>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without
>>>>>>>>>>>> modifications --> network does not work
>>>>>>>>>>>>
>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel
>>>>>>>>>>>> (r8169 mods only) --> network does not work
>>>>>>>>>>>>
>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169
>>>>>>>>>>>> mods -> devices show up ok, network works
>>>>>>>>>>>>
>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>
>>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable
>>>>>>>>>>> affected by a known BIOS bug.
>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>> In the first referenced tickets it's about the same
>>>>>>>>>>> mainboard (with earlier BIOS version).
>>>>>>>>>>> BIOS on this mainboard seems to not initialize the network
>>>>>>>>>>> chip / PHY correctly, it reports
>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being
>>>>>>>>>>> found.
>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem
>>>>>>>>>>> should be gone.
>>>>>>>>>>>
>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>
>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing
>>>>>>>>> some mutex guard for phy state and try to use it as indicator
>>>>>>>>>
>>>>>>>>> that attach has been done. One thing i've noticed is that
>>>>>>>>> driver needs to be reloaded to allow traffic (ie. ping works
>>>>>>>>> etc.)
>>>>>>>>>
>>>>>>>> All that shouldn't be needed. Just check with which PHY ID the
>>>>>>>> PHY comes up.
>>>>>>>> And what do you mean with "it seems"? Is the option enabled or
>>>>>>>> not?
>>>>>>>>
>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then you
>>>>> have the same
>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>
>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>> PHY version: 0xc2077002
>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>> MAC version: 23
>>>>
>>>> ....
>>>>
>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> PHY version: 0x1cc912
>>>>
>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> MAC version: 23
>>>>
>>>> .. after module unload & load cycle:
>>>>
>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> PHY version: 0x1cc912
>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> MAC version: 23
>>>>
>>>>
>>>> it seem to be the case that the phy_id chances onetime, then stays
>>>> the same. I'll do few shutdowns and see
>>>>
>>>> is there a pattern at all .. next i'm going to try how it behaves,
>>>> if i read mac/phy versions twice on MAC version 23.
>>>>
>>>>
>>>> The BIOS downgrade: I'd like to solve this without downgrading
>>>> BIOS. If I can't, then I'll do systemd-service that
>>>>
>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>
>>>>
>>> What i've gathered samples now, there is three values for PHY ID:
>>>
>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep
>>> "PHY ver"
>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> PHY version: 0xc2077002
>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>> PHY version: 0xc2077002
>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> PHY version: 0x1cc912
>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>> PHY version: 0x1cc912
>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> PHY version: 0x1cc912
>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>> PHY version: 0x1cc912
>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> PHY version: 0xc1071002
>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>> PHY version: 0xc1071002
>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> PHY version: 0x1cc912
>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>> PHY version: 0x1cc912
>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> PHY version: 0xc1071002
>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>> PHY version: 0xc1071002
>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> PHY version: 0x1cc912
>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>> PHY version: 0x1cc912
>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> PHY version: 0xc1071002
>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>> PHY version: 0xc1071002
>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>> PHY version: 0x1cc912
>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>> PHY version: 0x1cc912
>>>
>>> I dont know are those hard coded or what, and are they device
>>> specific how much.
>>>
>>> i haven't coldbooted things up, that may be that something to check
>>> do they vary how per coldboot.
>>>
>>>>>> I check the ID, and revert all other changes, and check how it is
>>>>>> working after adding the PHY id to list.
>>>>>>
>> What i've now learned: the patch + script + journald services ->
>> Results working network, but it is still a workaround.
>>
> Following patch trusts the MAC version, another thing witch could help
> is to derive method to do 2dn pass of the probeing:
>
> if specific MAC version is found.
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
> b/drivers/net/ethernet/realtek/r8169_main.c
> index acd122a88d4a..62b37a1abc24 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct
> rtl8169_private *tp)
> if (!tp->phydev) {
> mdiobus_unregister(new_bus);
> return -ENODEV;
> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
> - /* Most chip versions fail with the genphy driver.
> - * Therefore ensure that the dedicated PHY driver is
> loaded.
> - */
> - dev_err(&pdev->dev, "Not known MAC version.\n");
> - mdiobus_unregister(new_bus);
> - return -EUNATCH;
> + } else {
> + dev_info(&pdev->dev, "PHY version: 0x%x\n",
> tp->phydev->phy_id);
> + dev_info(&pdev->dev, "MAC version: %d\n",
> tp->mac_version);
> +
> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
> + /* Most chip versions fail with the genphy
> driver.
> + * Therefore ensure that the dedicated PHY
> driver is loaded.
> + */
> + dev_err(&pdev->dev, "Not known MAC/PHY
> version.\n", tp->phydev->phy_id);
> + mdiobus_unregister(new_bus);
> + return -EUNATCH;
> + }
> }
>
> /* PHY will be woken up in rtl_open() */
>
I just got bleeding edge 5.7.0-1 kernel compiled + firmware's updated..
and now up'n'running. There is one (WARN_ONCE) stack trace coming from
driver, i think i tinker with it next, with above patch the network
devices shows up and they can be configured.
>>
>>>>>>>>>>>> The problem with old method seems to be, that device does
>>>>>>>>>>>> not have had time to attach before the
>>>>>>>>>>>> PHY driver check.
>>>>>>>>>>>>
>>>>>>>>>>>> The patch:
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int
>>>>>>>>>>>> r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>> /* Most chip versions fail with the
>>>>>>>>>>>> genphy driver.
>>>>>>>>>>>> * Therefore ensure that the dedicated
>>>>>>>>>>>> PHY driver is loaded.
>>>>>>>>>>>> */
>>>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded,
>>>>>>>>>>>> maybe it needs to be added to initramfs?\n");
>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC
>>>>>>>>>>>> version.\n");
>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>> return -EUNATCH;
>>>>>>>>>>>> }
>>>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c
>>>>>>>>>>>> b/drivers/net/phy/phy-core.c
>>>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>> {
>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>> +
>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page,
>>>>>>>>>>>> "read_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct
>>>>>>>>>>>> phy_device *phydev)
>>>>>>>>>>>> static int __phy_write_page(struct phy_device
>>>>>>>>>>>> *phydev, int page)
>>>>>>>>>>>> {
>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>> +
>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page,
>>>>>>>>>>>> "write_page callback not available, PHY driver not
>>>>>>>>>>>> loaded?\n"))
>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>>>>>>> }
>>>>>>>>>>>> +
>>>>>>>>>>>> /**
>>>>>>>>>>>> * phy_save_page() - take the bus lock and save the
>>>>>>>>>>>> current page
>>>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit
>>>>>>>>>>>> <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>>
>>>>>>>>>>>> kirjoitti:
>>>>>>>>>>>>
>>>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi, There seems to he Something odd problem,
>>>>>>>>>>>> maybe timing related. Stripped version not workingas
>>>>>>>>>>>> expected. I get back to you, when i have it working.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> There's no point in working on your patch. W/o
>>>>>>>>>>>> proper justification it
>>>>>>>>>>>> isn't acceptable anyway. And so far we still don't
>>>>>>>>>>>> know which problem
>>>>>>>>>>>> you actually have.
>>>>>>>>>>>> FIRST please provide the requested logs and explain
>>>>>>>>>>>> the actual problem
>>>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku
>>>>>>>>>>>> <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti:
>>>>>>>>>>>> Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34,
>>>>>>>>>>>> Leon Romanovsky wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri
>>>>>>>>>>>> Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon
>>>>>>>>>>>> Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300,
>>>>>>>>>>>> Lauri Jakku wrote: From
>>>>>>>>>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17
>>>>>>>>>>>> 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13
>>>>>>>>>>>> Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169
>>>>>>>>>>>> identifying fix The driver installation determination made
>>>>>>>>>>>> properly by checking PHY vs DRIVER id's. ---
>>>>>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70
>>>>>>>>>>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11
>>>>>>>>>>>> +++- 2 files changed, 72 insertions(+), 9 deletions(-) I
>>>>>>>>>>>> would say that most of the code is debug prints. I tought
>>>>>>>>>>>> that they are helpful to keep, they are using the debug
>>>>>>>>>>>> calls, so they are not visible if user does not like those.
>>>>>>>>>>>> You are missing the point of who are your users. Users want
>>>>>>>>>>>> to have working device and the code. They don't need or
>>>>>>>>>>>> like to debug their kernel. Thanks
>>>>>>>>>>>>
>>>>>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-19 16:49 ` Lauri Jakku
@ 2020-04-19 16:00 ` Heiner Kallweit
2020-04-19 21:00 ` Lauri Jakku
2020-05-01 19:12 ` Lauri Jakku
0 siblings, 2 replies; 57+ messages in thread
From: Heiner Kallweit @ 2020-04-19 16:00 UTC (permalink / raw)
To: Lauri Jakku; +Cc: Leon Romanovsky, netdev, nic_swsd
On 19.04.2020 18:49, Lauri Jakku wrote:
> Hi,
>
> On 19.4.2020 18.09, Lauri Jakku wrote:
>> Hi,
>>
>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>
>>> Hi,
>>>
>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>
>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>>>>>>>>>>>
>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>
>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>>>>>>>>>>>
>>>>>>>>>>> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>>>>>>>
>>>>>>>>>> All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
>>>>>>>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>>>>>>>
>>>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then you have the same
>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>
>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: MAC version: 23
>>>>>>
>>>>>> ....
>>>>>>
>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>
>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>
>>>>>> .. after module unload & load cycle:
>>>>>>
>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>
>>>>>>
>>>>>> it seem to be the case that the phy_id chances onetime, then stays the same. I'll do few shutdowns and see
>>>>>>
>>>>>> is there a pattern at all .. next i'm going to try how it behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>
>>>>>>
>>>>>> The BIOS downgrade: I'd like to solve this without downgrading BIOS. If I can't, then I'll do systemd-service that
>>>>>>
>>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>>
>>>>>>
>>>>> What i've gathered samples now, there is three values for PHY ID:
>>>>>
>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep "PHY ver"
>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc2077002
>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>
>>>>> I dont know are those hard coded or what, and are they device specific how much.
>>>>>
>>>>> i haven't coldbooted things up, that may be that something to check do they vary how per coldboot.
>>>>>
>>>>>>>> I check the ID, and revert all other changes, and check how it is working after adding the PHY id to list.
>>>>>>>>
>>>> What i've now learned: the patch + script + journald services -> Results working network, but it is still a workaround.
>>>>
>>> Following patch trusts the MAC version, another thing witch could help is to derive method to do 2dn pass of the probeing:
>>>
>>> if specific MAC version is found.
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>> index acd122a88d4a..62b37a1abc24 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>> if (!tp->phydev) {
>>> mdiobus_unregister(new_bus);
>>> return -ENODEV;
>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>> - /* Most chip versions fail with the genphy driver.
>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>> - */
>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>> - mdiobus_unregister(new_bus);
>>> - return -EUNATCH;
>>> + } else {
>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>> +
>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>> + /* Most chip versions fail with the genphy driver.
>>> + * Therefore ensure that the dedicated PHY driver is loaded.
>>> + */
>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n", tp->phydev->phy_id);
>>> + mdiobus_unregister(new_bus);
>>> + return -EUNATCH;
>>> + }
>>> }
>>>
>>> /* PHY will be woken up in rtl_open() */
>>>
>>
>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's updated.. and now up'n'running. There is one (WARN_ONCE) stack trace coming from driver, i think i tinker with it next, with above patch the network devices shows up and they can be configured.
>>
>
> I tought to ask first, before going to make new probe_type for errorneus hw (propetype + retry counter) to do re-probe if requested, N times. Or should the r8169_main.c return deferred probe on error on some MAC enums ? Which approach is design-wise sound ?
>
> I just tought that the DEFERRED probe may just do the trick i'm looking ways to implement the re-probeing... hmm. I try the deferred thing and check would that help.
>
Playing with options to work around the issue is of course a great way to
learn about the kernel. However it's questionable whether a workaround in
the driver is acceptable for dealing with the broken BIOS of exactly one
> 10 yrs old board (for which even a userspace workaround exists).
>>>>
>>>>>>>>>>>>>> The problem with old method seems to be, that device does not have had time to attach before the
>>>>>>>>>>>>>> PHY driver check.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The patch:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>>>> /* Most chip versions fail with the genphy driver.
>>>>>>>>>>>>>> * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>> return -EUNATCH;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> /**
>>>>>>>>>>>>>> * phy_save_page() - take the bus lock and save the current page
>>>>>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi, There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There's no point in working on your patch. W/o proper justification it
>>>>>>>>>>>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>>>>>>>>>>>> you actually have.
>>>>>>>>>>>>>> FIRST please provide the requested logs and explain the actual problem
>>>>>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver installation determination made properly by checking PHY vs DRIVER id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files changed, 72 insertions(+), 9 deletions(-) I would say that most of the code is debug prints. I tought that they are helpful to keep, they are using the debug calls, so they are not visible if user does not like those. You are missing the point of who are your users. Users want to have working device and the code. They don't need or like to debug their kernel. Thanks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-19 15:09 ` Lauri Jakku
@ 2020-04-19 16:49 ` Lauri Jakku
2020-04-19 16:00 ` Heiner Kallweit
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-19 16:49 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 19.4.2020 18.09, Lauri Jakku wrote:
> Hi,
>
> On 18.4.2020 21.46, Lauri Jakku wrote:
>
>> Hi,
>>
>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>> Hi,
>>>
>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>
>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without
>>>>>>>>>>>>> modifications --> network does not work
>>>>>>>>>>>>>
>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel
>>>>>>>>>>>>> (r8169 mods only) --> network does not work
>>>>>>>>>>>>>
>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169
>>>>>>>>>>>>> mods -> devices show up ok, network works
>>>>>>>>>>>>>
>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable
>>>>>>>>>>>> affected by a known BIOS bug.
>>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>>> In the first referenced tickets it's about the same
>>>>>>>>>>>> mainboard (with earlier BIOS version).
>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the network
>>>>>>>>>>>> chip / PHY correctly, it reports
>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being
>>>>>>>>>>>> found.
>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem
>>>>>>>>>>>> should be gone.
>>>>>>>>>>>>
>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>
>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing
>>>>>>>>>> some mutex guard for phy state and try to use it as indicator
>>>>>>>>>>
>>>>>>>>>> that attach has been done. One thing i've noticed is that
>>>>>>>>>> driver needs to be reloaded to allow traffic (ie. ping works
>>>>>>>>>> etc.)
>>>>>>>>>>
>>>>>>>>> All that shouldn't be needed. Just check with which PHY ID the
>>>>>>>>> PHY comes up.
>>>>>>>>> And what do you mean with "it seems"? Is the option enabled or
>>>>>>>>> not?
>>>>>>>>>
>>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then you
>>>>>> have the same
>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>
>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>>> PHY version: 0xc2077002
>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>>> MAC version: 23
>>>>>
>>>>> ....
>>>>>
>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>>> PHY version: 0x1cc912
>>>>>
>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>>> MAC version: 23
>>>>>
>>>>> .. after module unload & load cycle:
>>>>>
>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>>> PHY version: 0x1cc912
>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>>> MAC version: 23
>>>>>
>>>>>
>>>>> it seem to be the case that the phy_id chances onetime, then stays
>>>>> the same. I'll do few shutdowns and see
>>>>>
>>>>> is there a pattern at all .. next i'm going to try how it behaves,
>>>>> if i read mac/phy versions twice on MAC version 23.
>>>>>
>>>>>
>>>>> The BIOS downgrade: I'd like to solve this without downgrading
>>>>> BIOS. If I can't, then I'll do systemd-service that
>>>>>
>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>
>>>>>
>>>> What i've gathered samples now, there is three values for PHY ID:
>>>>
>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep
>>>> "PHY ver"
>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> PHY version: 0xc2077002
>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>> PHY version: 0xc2077002
>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> PHY version: 0x1cc912
>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>> PHY version: 0x1cc912
>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> PHY version: 0x1cc912
>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>> PHY version: 0x1cc912
>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> PHY version: 0xc1071002
>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>> PHY version: 0xc1071002
>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> PHY version: 0x1cc912
>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>> PHY version: 0x1cc912
>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> PHY version: 0xc1071002
>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>> PHY version: 0xc1071002
>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> PHY version: 0x1cc912
>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>> PHY version: 0x1cc912
>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> PHY version: 0xc1071002
>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>> PHY version: 0xc1071002
>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0:
>>>> PHY version: 0x1cc912
>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0:
>>>> PHY version: 0x1cc912
>>>>
>>>> I dont know are those hard coded or what, and are they device
>>>> specific how much.
>>>>
>>>> i haven't coldbooted things up, that may be that something to check
>>>> do they vary how per coldboot.
>>>>
>>>>>>> I check the ID, and revert all other changes, and check how it
>>>>>>> is working after adding the PHY id to list.
>>>>>>>
>>> What i've now learned: the patch + script + journald services ->
>>> Results working network, but it is still a workaround.
>>>
>> Following patch trusts the MAC version, another thing witch could
>> help is to derive method to do 2dn pass of the probeing:
>>
>> if specific MAC version is found.
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>> b/drivers/net/ethernet/realtek/r8169_main.c
>> index acd122a88d4a..62b37a1abc24 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct
>> rtl8169_private *tp)
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is
>> loaded.
>> - */
>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>> - mdiobus_unregister(new_bus);
>> - return -EUNATCH;
>> + } else {
>> + dev_info(&pdev->dev, "PHY version: 0x%x\n",
>> tp->phydev->phy_id);
>> + dev_info(&pdev->dev, "MAC version: %d\n",
>> tp->mac_version);
>> +
>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>> + /* Most chip versions fail with the genphy
>> driver.
>> + * Therefore ensure that the dedicated PHY
>> driver is loaded.
>> + */
>> + dev_err(&pdev->dev, "Not known MAC/PHY
>> version.\n", tp->phydev->phy_id);
>> + mdiobus_unregister(new_bus);
>> + return -EUNATCH;
>> + }
>> }
>>
>> /* PHY will be woken up in rtl_open() */
>>
>
> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's
> updated.. and now up'n'running. There is one (WARN_ONCE) stack trace
> coming from driver, i think i tinker with it next, with above patch
> the network devices shows up and they can be configured.
>
I tought to ask first, before going to make new probe_type for errorneus
hw (propetype + retry counter) to do re-probe if requested, N times. Or
should the r8169_main.c return deferred probe on error on some MAC enums
? Which approach is design-wise sound ?
I just tought that the DEFERRED probe may just do the trick i'm looking
ways to implement the re-probeing... hmm. I try the deferred thing and
check would that help.
>>>
>>>>>>>>>>>>> The problem with old method seems to be, that device does
>>>>>>>>>>>>> not have had time to attach before the
>>>>>>>>>>>>> PHY driver check.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The patch:
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int
>>>>>>>>>>>>> r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>>> /* Most chip versions fail with the
>>>>>>>>>>>>> genphy driver.
>>>>>>>>>>>>> * Therefore ensure that the dedicated
>>>>>>>>>>>>> PHY driver is loaded.
>>>>>>>>>>>>> */
>>>>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not
>>>>>>>>>>>>> loaded, maybe it needs to be added to initramfs?\n");
>>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC
>>>>>>>>>>>>> version.\n");
>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>> return -EUNATCH;
>>>>>>>>>>>>> }
>>>>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>> b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page,
>>>>>>>>>>>>> "read_page callback not available, PHY driver not
>>>>>>>>>>>>> loaded?\n"))
>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>> @@ -712,12 +716,17 @@ static int
>>>>>>>>>>>>> __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>> static int __phy_write_page(struct phy_device
>>>>>>>>>>>>> *phydev, int page)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page,
>>>>>>>>>>>>> "write_page callback not available, PHY driver not
>>>>>>>>>>>>> loaded?\n"))
>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>>>>>>>> }
>>>>>>>>>>>>> +
>>>>>>>>>>>>> /**
>>>>>>>>>>>>> * phy_save_page() - take the bus lock and save the
>>>>>>>>>>>>> current page
>>>>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit
>>>>>>>>>>>>> <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>>
>>>>>>>>>>>>> kirjoitti:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi, There seems to he Something odd problem,
>>>>>>>>>>>>> maybe timing related. Stripped version not workingas
>>>>>>>>>>>>> expected. I get back to you, when i have it working.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> There's no point in working on your patch. W/o
>>>>>>>>>>>>> proper justification it
>>>>>>>>>>>>> isn't acceptable anyway. And so far we still don't
>>>>>>>>>>>>> know which problem
>>>>>>>>>>>>> you actually have.
>>>>>>>>>>>>> FIRST please provide the requested logs and explain
>>>>>>>>>>>>> the actual problem
>>>>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku
>>>>>>>>>>>>> <ljakku77@gmail.com <mailto:ljakku77@gmail.com>>
>>>>>>>>>>>>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On
>>>>>>>>>>>>> 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri
>>>>>>>>>>>>> Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58,
>>>>>>>>>>>>> Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM
>>>>>>>>>>>>> +0300, Lauri Jakku wrote: From
>>>>>>>>>>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17
>>>>>>>>>>>>> 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13
>>>>>>>>>>>>> Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169
>>>>>>>>>>>>> identifying fix The driver installation determination made
>>>>>>>>>>>>> properly by checking PHY vs DRIVER id's. ---
>>>>>>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70
>>>>>>>>>>>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11
>>>>>>>>>>>>> +++- 2 files changed, 72 insertions(+), 9 deletions(-) I
>>>>>>>>>>>>> would say that most of the code is debug prints. I tought
>>>>>>>>>>>>> that they are helpful to keep, they are using the debug
>>>>>>>>>>>>> calls, so they are not visible if user does not like
>>>>>>>>>>>>> those. You are missing the point of who are your users.
>>>>>>>>>>>>> Users want to have working device and the code. They don't
>>>>>>>>>>>>> need or like to debug their kernel. Thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-19 16:00 ` Heiner Kallweit
@ 2020-04-19 21:00 ` Lauri Jakku
2020-04-20 19:56 ` Lauri Jakku
2020-05-01 19:12 ` Lauri Jakku
1 sibling, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-04-19 21:00 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
On 19.4.2020 19.00, Heiner Kallweit wrote:
> On 19.04.2020 18:49, Lauri Jakku wrote:
>> Hi,
>>
>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>> Hi,
>>>
>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>
>>>> Hi,
>>>>
>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>>>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>
>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>>>>>>>>>>>>
>>>>>>>>>>>> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>>>>>>>>
>>>>>>>>>>> All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
>>>>>>>>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>>>>>>>>
>>>>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then you have the same
>>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>>
>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: MAC version: 23
>>>>>>>
>>>>>>> ....
>>>>>>>
>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>
>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>
>>>>>>> .. after module unload & load cycle:
>>>>>>>
>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>
>>>>>>>
>>>>>>> it seem to be the case that the phy_id chances onetime, then stays the same. I'll do few shutdowns and see
>>>>>>>
>>>>>>> is there a pattern at all .. next i'm going to try how it behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>>
>>>>>>>
>>>>>>> The BIOS downgrade: I'd like to solve this without downgrading BIOS. If I can't, then I'll do systemd-service that
>>>>>>>
>>>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>>>
>>>>>>>
>>>>>> What i've gathered samples now, there is three values for PHY ID:
>>>>>>
>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep "PHY ver"
>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc2077002
>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>
>>>>>> I dont know are those hard coded or what, and are they device specific how much.
>>>>>>
>>>>>> i haven't coldbooted things up, that may be that something to check do they vary how per coldboot.
>>>>>>
>>>>>>>>> I check the ID, and revert all other changes, and check how it is working after adding the PHY id to list.
>>>>>>>>>
>>>>> What i've now learned: the patch + script + journald services -> Results working network, but it is still a workaround.
>>>>>
>>>> Following patch trusts the MAC version, another thing witch could help is to derive method to do 2dn pass of the probeing:
>>>>
>>>> if specific MAC version is found.
>>>>
>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>> index acd122a88d4a..62b37a1abc24 100644
>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>> if (!tp->phydev) {
>>>> mdiobus_unregister(new_bus);
>>>> return -ENODEV;
>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>> - /* Most chip versions fail with the genphy driver.
>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>> - */
>>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>>> - mdiobus_unregister(new_bus);
>>>> - return -EUNATCH;
>>>> + } else {
>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>>> +
>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>> + /* Most chip versions fail with the genphy driver.
>>>> + * Therefore ensure that the dedicated PHY driver is loaded.
>>>> + */
>>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n", tp->phydev->phy_id);
>>>> + mdiobus_unregister(new_bus);
>>>> + return -EUNATCH;
>>>> + }
>>>> }
>>>>
>>>> /* PHY will be woken up in rtl_open() */
>>>>
>>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's updated.. and now up'n'running. There is one (WARN_ONCE) stack trace coming from driver, i think i tinker with it next, with above patch the network devices shows up and they can be configured.
>>>
>> I tought to ask first, before going to make new probe_type for errorneus hw (propetype + retry counter) to do re-probe if requested, N times. Or should the r8169_main.c return deferred probe on error on some MAC enums ? Which approach is design-wise sound ?
>>
>> I just tought that the DEFERRED probe may just do the trick i'm looking ways to implement the re-probeing... hmm. I try the deferred thing and check would that help.
>>
> Playing with options to work around the issue is of course a great way to
> learn about the kernel. However it's questionable whether a workaround in
> the driver is acceptable for dealing with the broken BIOS of exactly one
Hmm, I think that it is better to have devices supported, even if the HW
is old, and cause it has had support.
There are even older harddisk & network drivers, so the argument is not
good, thus i see no reason why not
to take patch in.
>> 10 yrs old board (for which even a userspace workaround exists).
The age of driver has never been the thing .. there are very old
drivers, HDD and Network etc.
>>>>>>>>>>>>>>> The problem with old method seems to be, that device does not have had time to attach before the
>>>>>>>>>>>>>>> PHY driver check.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The patch:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>>>>> /* Most chip versions fail with the genphy driver.
>>>>>>>>>>>>>>> * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>> return -EUNATCH;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> /**
>>>>>>>>>>>>>>> * phy_save_page() - take the bus lock and save the current page
>>>>>>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi, There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There's no point in working on your patch. W/o proper justification it
>>>>>>>>>>>>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>>>>>>>>>>>>> you actually have.
>>>>>>>>>>>>>>> FIRST please provide the requested logs and explain the actual problem
>>>>>>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver installation determination made properly by checking PHY vs DRIVER id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files changed, 72 insertions(+), 9 deletions(-) I would say that most of the code is debug prints. I tought that they are helpful to keep, they are using the debug calls, so they are not visible if user does not like those. You are missing the point of who are your users. Users want to have working device and the code. They don't need or like to debug their kernel. Thanks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-19 21:00 ` Lauri Jakku
@ 2020-04-20 19:56 ` Lauri Jakku
0 siblings, 0 replies; 57+ messages in thread
From: Lauri Jakku @ 2020-04-20 19:56 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 20.4.2020 0.00, Lauri Jakku wrote:
>
> On 19.4.2020 19.00, Heiner Kallweit wrote:
>> On 19.04.2020 18:49, Lauri Jakku wrote:
>>> Hi,
>>>
>>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without
>>>>>>>>>>>>>>>> modifications --> network does not work
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel
>>>>>>>>>>>>>>>> (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched +
>>>>>>>>>>>>>>>> r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable
>>>>>>>>>>>>>>> affected by a known BIOS bug.
>>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>>>>>> In the first referenced tickets it's about the same
>>>>>>>>>>>>>>> mainboard (with earlier BIOS version).
>>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the
>>>>>>>>>>>>>>> network chip / PHY correctly, it reports
>>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver
>>>>>>>>>>>>>>> being found.
>>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your
>>>>>>>>>>>>>>> problem should be gone.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing
>>>>>>>>>>>>> some mutex guard for phy state and try to use it as indicator
>>>>>>>>>>>>>
>>>>>>>>>>>>> that attach has been done. One thing i've noticed is that
>>>>>>>>>>>>> driver needs to be reloaded to allow traffic (ie. ping
>>>>>>>>>>>>> works etc.)
>>>>>>>>>>>>>
>>>>>>>>>>>> All that shouldn't be needed. Just check with which PHY ID
>>>>>>>>>>>> the PHY comes up.
>>>>>>>>>>>> And what do you mean with "it seems"? Is the option enabled
>>>>>>>>>>>> or not?
>>>>>>>>>>>>
>>>>>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then
>>>>>>>>> you have the same
>>>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>>>
>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: MAC version: 23
>>>>>>>>
>>>>>>>> ....
>>>>>>>>
>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>
>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: MAC version: 23
>>>>>>>>
>>>>>>>> .. after module unload & load cycle:
>>>>>>>>
>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: MAC version: 23
>>>>>>>>
>>>>>>>>
>>>>>>>> it seem to be the case that the phy_id chances onetime, then
>>>>>>>> stays the same. I'll do few shutdowns and see
>>>>>>>>
>>>>>>>> is there a pattern at all .. next i'm going to try how it
>>>>>>>> behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>>>
>>>>>>>>
>>>>>>>> The BIOS downgrade: I'd like to solve this without downgrading
>>>>>>>> BIOS. If I can't, then I'll do systemd-service that
>>>>>>>>
>>>>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>>>>
>>>>>>>>
>>>>>>> What i've gathered samples now, there is three values for PHY ID:
>>>>>>>
>>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep
>>>>>>> "PHY ver"
>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0xc2077002
>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0xc2077002
>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>
>>>>>>> I dont know are those hard coded or what, and are they device
>>>>>>> specific how much.
>>>>>>>
>>>>>>> i haven't coldbooted things up, that may be that something to
>>>>>>> check do they vary how per coldboot.
>>>>>>>
>>>>>>>>>> I check the ID, and revert all other changes, and check how
>>>>>>>>>> it is working after adding the PHY id to list.
>>>>>>>>>>
>>>>>> What i've now learned: the patch + script + journald services ->
>>>>>> Results working network, but it is still a workaround.
>>>>>>
>>>>> Following patch trusts the MAC version, another thing witch could
>>>>> help is to derive method to do 2dn pass of the probeing:
>>>>>
>>>>> if specific MAC version is found.
>>>>>
>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>> index acd122a88d4a..62b37a1abc24 100644
>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct
>>>>> rtl8169_private *tp)
>>>>> if (!tp->phydev) {
>>>>> mdiobus_unregister(new_bus);
>>>>> return -ENODEV;
>>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>> - /* Most chip versions fail with the genphy driver.
>>>>> - * Therefore ensure that the dedicated PHY driver
>>>>> is loaded.
>>>>> - */
>>>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>> - mdiobus_unregister(new_bus);
>>>>> - return -EUNATCH;
>>>>> + } else {
>>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n",
>>>>> tp->phydev->phy_id);
>>>>> + dev_info(&pdev->dev, "MAC version: %d\n",
>>>>> tp->mac_version);
>>>>> +
>>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>> + /* Most chip versions fail with the genphy
>>>>> driver.
>>>>> + * Therefore ensure that the dedicated PHY
>>>>> driver is loaded.
>>>>> + */
>>>>> + dev_err(&pdev->dev, "Not known MAC/PHY
>>>>> version.\n", tp->phydev->phy_id);
>>>>> + mdiobus_unregister(new_bus);
>>>>> + return -EUNATCH;
>>>>> + }
>>>>> }
>>>>>
>>>>> /* PHY will be woken up in rtl_open() */
>>>>>
>>>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's
>>>> updated.. and now up'n'running. There is one (WARN_ONCE) stack
>>>> trace coming from driver, i think i tinker with it next, with above
>>>> patch the network devices shows up and they can be configured.
>>>>
>>> I tought to ask first, before going to make new probe_type for
>>> errorneus hw (propetype + retry counter) to do re-probe if
>>> requested, N times. Or should the r8169_main.c return deferred probe
>>> on error on some MAC enums ? Which approach is design-wise sound ?
>>>
>>> I just tought that the DEFERRED probe may just do the trick i'm
>>> looking ways to implement the re-probeing... hmm. I try the deferred
>>> thing and check would that help.
>>>
>> Playing with options to work around the issue is of course a great
>> way to
>> learn about the kernel. However it's questionable whether a
>> workaround in
>> the driver is acceptable for dealing with the broken BIOS of exactly one
>
> Hmm, I think that it is better to have devices supported, even if the
> HW is old, and cause it has had support.
>
> There are even older harddisk & network drivers, so the argument is
> not good, thus i see no reason why not
>
> to take patch in.
>
>
>>> 10 yrs old board (for which even a userspace workaround exists).
> The age of driver has never been the thing .. there are very old
> drivers, HDD and Network etc.
>>>>>>>>>>>>>>>> The problem with old method seems to be, that device
>>>>>>>>>>>>>>>> does not have had time to attach before the
I think i have now good combination of driver, that does the old trick
on real non realtek NICs + userspace added configuration. See at Manjaro
forum https://forum.manjaro.org/t/r8168-kernel-5-6-3-driver-broken/135325/10
for them for meantime. I think the 'refresh' within kernel, is doable,
but there is quite much i don't still know how kernel works, so my
solution might be bit more hacky and slashy,
i try to do some elegant ish solution, but the kernel patch + those
systemd files are for those by-all-means-hack-fixers.
>>>>>>>>>>>>>>>> PHY driver check.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The patch:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int
>>>>>>>>>>>>>>>> r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>>>>>> /* Most chip versions fail with the
>>>>>>>>>>>>>>>> genphy driver.
>>>>>>>>>>>>>>>> * Therefore ensure that the
>>>>>>>>>>>>>>>> dedicated PHY driver is loaded.
>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it
>>>>>>>>>>>>>>>> needs to be added to initramfs?\n");
>>>>>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>>> return -EUNATCH;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>> b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>>>>>>>> static int __phy_read_page(struct phy_device
>>>>>>>>>>>>>>>> *phydev)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page,
>>>>>>>>>>>>>>>> "read_page callback not available, PHY driver not
>>>>>>>>>>>>>>>> loaded?\n"))
>>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>>> @@ -712,12 +716,17 @@ static int
>>>>>>>>>>>>>>>> __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>>>> static int __phy_write_page(struct phy_device
>>>>>>>>>>>>>>>> *phydev, int page)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page,
>>>>>>>>>>>>>>>> "write_page callback not available, PHY driver not
>>>>>>>>>>>>>>>> loaded?\n"))
>>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>>> return phydev->drv->write_page(phydev,
>>>>>>>>>>>>>>>> page);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> /**
>>>>>>>>>>>>>>>> * phy_save_page() - take the bus lock and save
>>>>>>>>>>>>>>>> the current page
>>>>>>>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit
>>>>>>>>>>>>>>>> <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>>
>>>>>>>>>>>>>>>> kirjoitti:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi, There seems to he Something odd
>>>>>>>>>>>>>>>> problem, maybe timing related. Stripped version not
>>>>>>>>>>>>>>>> workingas expected. I get back to you, when i have it
>>>>>>>>>>>>>>>> working.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There's no point in working on your patch. W/o
>>>>>>>>>>>>>>>> proper justification it
>>>>>>>>>>>>>>>> isn't acceptable anyway. And so far we still
>>>>>>>>>>>>>>>> don't know which problem
>>>>>>>>>>>>>>>> you actually have.
>>>>>>>>>>>>>>>> FIRST please provide the requested logs and
>>>>>>>>>>>>>>>> explain the actual problem
>>>>>>>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku
>>>>>>>>>>>>>>>> <ljakku77@gmail.com <mailto:ljakku77@gmail.com>>
>>>>>>>>>>>>>>>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On
>>>>>>>>>>>>>>>> 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300,
>>>>>>>>>>>>>>>> Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13
>>>>>>>>>>>>>>>> 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at
>>>>>>>>>>>>>>>> 01:30:13PM +0300, Lauri Jakku wrote: From
>>>>>>>>>>>>>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17
>>>>>>>>>>>>>>>> 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon,
>>>>>>>>>>>>>>>> 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET:
>>>>>>>>>>>>>>>> r8168/r8169 identifying fix The driver installation
>>>>>>>>>>>>>>>> determination made properly by checking PHY vs DRIVER
>>>>>>>>>>>>>>>> id's. --- drivers/net/ethernet/realtek/r8169_main.c |
>>>>>>>>>>>>>>>> 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c |
>>>>>>>>>>>>>>>> 11 +++- 2 files changed, 72 insertions(+), 9
>>>>>>>>>>>>>>>> deletions(-) I would say that most of the code is debug
>>>>>>>>>>>>>>>> prints. I tought that they are helpful to keep, they
>>>>>>>>>>>>>>>> are using the debug calls, so they are not visible if
>>>>>>>>>>>>>>>> user does not like those. You are missing the point of
>>>>>>>>>>>>>>>> who are your users. Users want to have working device
>>>>>>>>>>>>>>>> and the code. They don't need or like to debug their
>>>>>>>>>>>>>>>> kernel. Thanks
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-19 16:00 ` Heiner Kallweit
2020-04-19 21:00 ` Lauri Jakku
@ 2020-05-01 19:12 ` Lauri Jakku
2020-05-02 17:56 ` Lauri Jakku
1 sibling, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-05-01 19:12 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 19.4.2020 19.00, Heiner Kallweit wrote:
> On 19.04.2020 18:49, Lauri Jakku wrote:
>> Hi,
>>
>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>> Hi,
>>>
>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>
>>>> Hi,
>>>>
>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>>>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>
>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>>>>>>>>>>>>
>>>>>>>>>>>> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>>>>>>>>
>>>>>>>>>>> All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
>>>>>>>>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>>>>>>>>
>>>>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then you have the same
>>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>>
>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: MAC version: 23
>>>>>>>
>>>>>>> ....
>>>>>>>
>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>
>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>
>>>>>>> .. after module unload & load cycle:
>>>>>>>
>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>
>>>>>>>
>>>>>>> it seem to be the case that the phy_id chances onetime, then stays the same. I'll do few shutdowns and see
>>>>>>>
>>>>>>> is there a pattern at all .. next i'm going to try how it behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>>
>>>>>>>
>>>>>>> The BIOS downgrade: I'd like to solve this without downgrading BIOS. If I can't, then I'll do systemd-service that
>>>>>>>
>>>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>>>
>>>>>>>
>>>>>> What i've gathered samples now, there is three values for PHY ID:
>>>>>>
>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep "PHY ver"
>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc2077002
>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>
>>>>>> I dont know are those hard coded or what, and are they device specific how much.
>>>>>>
>>>>>> i haven't coldbooted things up, that may be that something to check do they vary how per coldboot.
>>>>>>
>>>>>>>>> I check the ID, and revert all other changes, and check how it is working after adding the PHY id to list.
>>>>>>>>>
>>>>> What i've now learned: the patch + script + journald services -> Results working network, but it is still a workaround.
>>>>>
>>>> Following patch trusts the MAC version, another thing witch could help is to derive method to do 2dn pass of the probeing:
>>>>
>>>> if specific MAC version is found.
>>>>
>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>> index acd122a88d4a..62b37a1abc24 100644
>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>> if (!tp->phydev) {
>>>> mdiobus_unregister(new_bus);
>>>> return -ENODEV;
>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>> - /* Most chip versions fail with the genphy driver.
>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>> - */
>>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>>> - mdiobus_unregister(new_bus);
>>>> - return -EUNATCH;
>>>> + } else {
>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>>> +
>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>> + /* Most chip versions fail with the genphy driver.
>>>> + * Therefore ensure that the dedicated PHY driver is loaded.
>>>> + */
>>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n", tp->phydev->phy_id);
>>>> + mdiobus_unregister(new_bus);
>>>> + return -EUNATCH;
>>>> + }
>>>> }
>>>>
>>>> /* PHY will be woken up in rtl_open() */
>>>>
>>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's updated.. and now up'n'running. There is one (WARN_ONCE) stack trace coming from driver, i think i tinker with it next, with above patch the network devices shows up and they can be configured.
>>>
>> I tought to ask first, before going to make new probe_type for errorneus hw (propetype + retry counter) to do re-probe if requested, N times. Or should the r8169_main.c return deferred probe on error on some MAC enums ? Which approach is design-wise sound ?
>>
>> I just tought that the DEFERRED probe may just do the trick i'm looking ways to implement the re-probeing... hmm. I try the deferred thing and check would that help.
>>
> Playing with options to work around the issue is of course a great way to
> learn about the kernel. However it's questionable whether a workaround in
> the driver is acceptable for dealing with the broken BIOS of exactly one
>> 10 yrs old board (for which even a userspace workaround exists).
problem recognized: libphy-module get's unloaded for some reason before
r8169 driver loads -> missing lowlevel functionality -> not working
driver. This only occurs at 1st load of module.. seeking solution.
There is [last unloaded: libphy] entries in log BEFORE r8169 is probed
first time.
Any clue what is responsible for unloading to occur ?
>>>>>>>>>>>>>>> The problem with old method seems to be, that device does not have had time to attach before the
>>>>>>>>>>>>>>> PHY driver check.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The patch:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>>>>> /* Most chip versions fail with the genphy driver.
>>>>>>>>>>>>>>> * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>> return -EUNATCH;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> /**
>>>>>>>>>>>>>>> * phy_save_page() - take the bus lock and save the current page
>>>>>>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi, There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There's no point in working on your patch. W/o proper justification it
>>>>>>>>>>>>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>>>>>>>>>>>>> you actually have.
>>>>>>>>>>>>>>> FIRST please provide the requested logs and explain the actual problem
>>>>>>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver installation determination made properly by checking PHY vs DRIVER id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files changed, 72 insertions(+), 9 deletions(-) I would say that most of the code is debug prints. I tought that they are helpful to keep, they are using the debug calls, so they are not visible if user does not like those. You are missing the point of who are your users. Users want to have working device and the code. They don't need or like to debug their kernel. Thanks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-05-01 19:12 ` Lauri Jakku
@ 2020-05-02 17:56 ` Lauri Jakku
2020-05-02 22:48 ` Lauri Jakku
[not found] ` <5cdc7f73-b109-2a37-8473-12889506b6a9@pp.inet.fi>
0 siblings, 2 replies; 57+ messages in thread
From: Lauri Jakku @ 2020-05-02 17:56 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 1.5.2020 22.12, Lauri Jakku wrote:
> Hi,
>
>
> On 19.4.2020 19.00, Heiner Kallweit wrote:
>> On 19.04.2020 18:49, Lauri Jakku wrote:
>>> Hi,
>>>
>>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without
>>>>>>>>>>>>>>>> modifications --> network does not work
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel
>>>>>>>>>>>>>>>> (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched +
>>>>>>>>>>>>>>>> r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable
>>>>>>>>>>>>>>> affected by a known BIOS bug.
>>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>>>>>> In the first referenced tickets it's about the same
>>>>>>>>>>>>>>> mainboard (with earlier BIOS version).
>>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the
>>>>>>>>>>>>>>> network chip / PHY correctly, it reports
>>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver
>>>>>>>>>>>>>>> being found.
>>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your
>>>>>>>>>>>>>>> problem should be gone.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing
>>>>>>>>>>>>> some mutex guard for phy state and try to use it as indicator
>>>>>>>>>>>>>
>>>>>>>>>>>>> that attach has been done. One thing i've noticed is that
>>>>>>>>>>>>> driver needs to be reloaded to allow traffic (ie. ping
>>>>>>>>>>>>> works etc.)
>>>>>>>>>>>>>
>>>>>>>>>>>> All that shouldn't be needed. Just check with which PHY ID
>>>>>>>>>>>> the PHY comes up.
>>>>>>>>>>>> And what do you mean with "it seems"? Is the option enabled
>>>>>>>>>>>> or not?
>>>>>>>>>>>>
>>>>>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then
>>>>>>>>> you have the same
>>>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>>>
>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: MAC version: 23
>>>>>>>>
>>>>>>>> ....
>>>>>>>>
>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>
>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: MAC version: 23
>>>>>>>>
>>>>>>>> .. after module unload & load cycle:
>>>>>>>>
>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: MAC version: 23
>>>>>>>>
>>>>>>>>
>>>>>>>> it seem to be the case that the phy_id chances onetime, then
>>>>>>>> stays the same. I'll do few shutdowns and see
>>>>>>>>
>>>>>>>> is there a pattern at all .. next i'm going to try how it
>>>>>>>> behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>>>
>>>>>>>>
>>>>>>>> The BIOS downgrade: I'd like to solve this without downgrading
>>>>>>>> BIOS. If I can't, then I'll do systemd-service that
>>>>>>>>
>>>>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>>>>
>>>>>>>>
>>>>>>> What i've gathered samples now, there is three values for PHY ID:
>>>>>>>
>>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep
>>>>>>> "PHY ver"
>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0xc2077002
>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0xc2077002
>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169
>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>
>>>>>>> I dont know are those hard coded or what, and are they device
>>>>>>> specific how much.
>>>>>>>
>>>>>>> i haven't coldbooted things up, that may be that something to
>>>>>>> check do they vary how per coldboot.
>>>>>>>
>>>>>>>>>> I check the ID, and revert all other changes, and check how
>>>>>>>>>> it is working after adding the PHY id to list.
>>>>>>>>>>
>>>>>> What i've now learned: the patch + script + journald services ->
>>>>>> Results working network, but it is still a workaround.
>>>>>>
>>>>> Following patch trusts the MAC version, another thing witch could
>>>>> help is to derive method to do 2dn pass of the probeing:
>>>>>
>>>>> if specific MAC version is found.
>>>>>
>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>> index acd122a88d4a..62b37a1abc24 100644
>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct
>>>>> rtl8169_private *tp)
>>>>> if (!tp->phydev) {
>>>>> mdiobus_unregister(new_bus);
>>>>> return -ENODEV;
>>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>> - /* Most chip versions fail with the genphy driver.
>>>>> - * Therefore ensure that the dedicated PHY driver
>>>>> is loaded.
>>>>> - */
>>>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>> - mdiobus_unregister(new_bus);
>>>>> - return -EUNATCH;
>>>>> + } else {
>>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n",
>>>>> tp->phydev->phy_id);
>>>>> + dev_info(&pdev->dev, "MAC version: %d\n",
>>>>> tp->mac_version);
>>>>> +
>>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>> + /* Most chip versions fail with the genphy
>>>>> driver.
>>>>> + * Therefore ensure that the dedicated PHY
>>>>> driver is loaded.
>>>>> + */
>>>>> + dev_err(&pdev->dev, "Not known MAC/PHY
>>>>> version.\n", tp->phydev->phy_id);
>>>>> + mdiobus_unregister(new_bus);
>>>>> + return -EUNATCH;
>>>>> + }
>>>>> }
>>>>>
>>>>> /* PHY will be woken up in rtl_open() */
>>>>>
>>>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's
>>>> updated.. and now up'n'running. There is one (WARN_ONCE) stack
>>>> trace coming from driver, i think i tinker with it next, with above
>>>> patch the network devices shows up and they can be configured.
>>>>
>>> I tought to ask first, before going to make new probe_type for
>>> errorneus hw (propetype + retry counter) to do re-probe if
>>> requested, N times. Or should the r8169_main.c return deferred probe
>>> on error on some MAC enums ? Which approach is design-wise sound ?
>>>
>>> I just tought that the DEFERRED probe may just do the trick i'm
>>> looking ways to implement the re-probeing... hmm. I try the deferred
>>> thing and check would that help.
>>>
>> Playing with options to work around the issue is of course a great
>> way to
>> learn about the kernel. However it's questionable whether a
>> workaround in
>> the driver is acceptable for dealing with the broken BIOS of exactly one
>>> 10 yrs old board (for which even a userspace workaround exists).
>
> problem recognized: libphy-module get's unloaded for some reason
> before r8169 driver loads -> missing lowlevel functionality -> not
> working driver. This only occurs at 1st load of module.. seeking
> solution.
>
>
> There is [last unloaded: libphy] entries in log BEFORE r8169 is probed
> first time.
>
>
> Any clue what is responsible for unloading to occur ?
>
>
Right now I'm debugging what is the reason, behind that the module
starts to work properly only when
unload & reload cycle is done.
The libphy is listed as loaded, but the check for low level read/write
function is not set -> r8169 modules rlt_open() fails.
See here:
touko 02 20:40:04 MinistryOfSillyWalk kernel: ------------[ cut here
]------------
touko 02 20:40:04 MinistryOfSillyWalk kernel: read_page callback not
available, PHY driver not loaded?
touko 02 20:40:04 MinistryOfSillyWalk kernel: WARNING: CPU: 3 PID: 787
at drivers/net/phy/phy-core.c:750 phy_save_page+0xb1/0xe3 [libph
y]
touko 02 20:40:04 MinistryOfSillyWalk kernel: Modules linked in: cmac
algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel b
luetooth ecdh_generic rfkill ecc uvcvideo videobuf2_vmalloc
videobuf2_memops snd_usb_audio videobuf2_v4l2 videobuf2_common snd_usbmidi_
lib videodev snd_rawmidi snd_seq_device mc input_leds joydev mousedev
squashfs loop amdgpu snd_hda_codec_realtek gpu_sched i2c_algo_bit
ttm snd_hda_codec_generic drm_kms_helper edac_mce_amd ledtrig_audio
cec rc_core kvm_amd drm ccp snd_hda_codec_hdmi agpgart rng_core kv
m snd_hda_intel syscopyarea sysfillrect ppdev sysimgblt snd_intel_dspcfg
fb_sys_fops snd_hda_codec snd_hda_core snd_hwdep irqbypass wmi
_bmof snd_pcm snd_timer snd evdev pcspkr soundcore parport_pc parport
sp5100_tco mac_hid i2c_piix4 k10temp acpi_cpufreq uinput crypto_u
ser ip_tables x_tables hid_generic usbhid hid ohci_pci virtio_net
net_failover failover firewire_ohci firewire_core crc_itu_t pata_atii
xp ehci_pci ehci_hcd sr_mod cdrom ohci_hcd ata_generic pata_acpi
pata_jmicron wmi floppy
touko 02 20:40:04 MinistryOfSillyWalk kernel: r8169 realtek libphy
touko 02 20:40:04 MinistryOfSillyWalk kernel: CPU: 3 PID: 787 Comm:
NetworkManager Not tainted 5.7.0-1-raw #12
touko 02 20:40:04 MinistryOfSillyWalk kernel: Hardware name: Gigabyte
Technology Co., Ltd. GA-MA790FXT-UD5P/GA-MA790FXT-UD5P, BIOS F8l 07/15/2010
touko 02 20:40:04 MinistryOfSillyWalk kernel: RIP:
0010:phy_save_page+0xb1/0xe3 [libphy]
touko 02 20:40:04 MinistryOfSillyWalk kernel: Code: c8 82 11 c0 e8 06 28
ff cc 85 db 74 47 48 8b 85 48 03 00 00 48 83 b8 68 01 00 00 00 75 10 48
c7 c7 e8 82 11 c0 e8 a9 dd f7 cc <0f> 0b eb 26 48 c7 c7 52 78 11 c0 e8
99 dd f7 cc 0f 0b 48 8b 85 48
touko 02 20:40:04 MinistryOfSillyWalk kernel: RSP: 0018:ffff962c408ef370
EFLAGS: 00010282
touko 02 20:40:04 MinistryOfSillyWalk kernel: RAX: 0000000000000000 RBX:
0000000000000001 RCX: 0000000000000000
touko 02 20:40:04 MinistryOfSillyWalk kernel: RDX: 0000000000000001 RSI:
0000000000000092 RDI: 00000000ffffffff
touko 02 20:40:05 MinistryOfSillyWalk kernel: RBP: ffff8b1af3eb8800 R08:
00000000000004b3 R09: 0000000000000004
touko 02 20:40:05 MinistryOfSillyWalk kernel: R10: 0000000000000000 R11:
0000000000000001 R12: 00000000ffffffa1
touko 02 20:40:05 MinistryOfSillyWalk kernel: R13: 0000000000000002 R14:
0000000000000002 R15: ffff8b1af3eb8800
touko 02 20:40:05 MinistryOfSillyWalk kernel: FS: 00007f07be5d4d80(0000)
GS:ffff8b1af7cc0000(0000) knlGS:0000000000000000
touko 02 20:40:05 MinistryOfSillyWalk kernel: CS: 0010 DS: 0000 ES:
0000 CR0: 0000000080050033
touko 02 20:40:05 MinistryOfSillyWalk kernel: CR2: 000055b83aecb008 CR3:
00000002246b0000 CR4: 00000000000006e0
touko 02 20:40:05 MinistryOfSillyWalk kernel: Call Trace:
touko 02 20:40:05 MinistryOfSillyWalk kernel: phy_select_page+0x53/0x7a
[libphy]
touko 02 20:40:05 MinistryOfSillyWalk kernel: phy_write_paged+0x5c/0xa0
[libphy]
touko 02 20:40:05 MinistryOfSillyWalk kernel:
rtl8168d_1_hw_phy_config+0x9d/0x210 [r8169]
touko 02 20:40:05 MinistryOfSillyWalk kernel:
rtl8169_init_phy+0x19/0x110 [r8169]
touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl_open+0x354/0x4d0 [r8169]
touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_open+0xe0/0x170
touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_change_flags+0x188/0x1e0
touko 02 20:40:05 MinistryOfSillyWalk kernel: dev_change_flags+0x21/0x60
touko 02 20:40:05 MinistryOfSillyWalk kernel: do_setlink+0x78a/0xfd0
Something does not setup/register properly at first the way it should.
>>>>>>>>>>>>>>>> The problem with old method seems to be, that device
>>>>>>>>>>>>>>>> does not have had time to attach before the
>>>>>>>>>>>>>>>> PHY driver check.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The patch:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int
>>>>>>>>>>>>>>>> r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>>>>>> /* Most chip versions fail with the
>>>>>>>>>>>>>>>> genphy driver.
>>>>>>>>>>>>>>>> * Therefore ensure that the
>>>>>>>>>>>>>>>> dedicated PHY driver is loaded.
>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it
>>>>>>>>>>>>>>>> needs to be added to initramfs?\n");
>>>>>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>>> return -EUNATCH;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>> b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>>>>>>>> static int __phy_read_page(struct phy_device
>>>>>>>>>>>>>>>> *phydev)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page,
>>>>>>>>>>>>>>>> "read_page callback not available, PHY driver not
>>>>>>>>>>>>>>>> loaded?\n"))
>>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>>> @@ -712,12 +716,17 @@ static int
>>>>>>>>>>>>>>>> __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>>>> static int __phy_write_page(struct phy_device
>>>>>>>>>>>>>>>> *phydev, int page)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page,
>>>>>>>>>>>>>>>> "write_page callback not available, PHY driver not
>>>>>>>>>>>>>>>> loaded?\n"))
>>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>>> return phydev->drv->write_page(phydev,
>>>>>>>>>>>>>>>> page);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> /**
>>>>>>>>>>>>>>>> * phy_save_page() - take the bus lock and save
>>>>>>>>>>>>>>>> the current page
>>>>>>>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit
>>>>>>>>>>>>>>>> <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>>
>>>>>>>>>>>>>>>> kirjoitti:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi, There seems to he Something odd
>>>>>>>>>>>>>>>> problem, maybe timing related. Stripped version not
>>>>>>>>>>>>>>>> workingas expected. I get back to you, when i have it
>>>>>>>>>>>>>>>> working.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There's no point in working on your patch. W/o
>>>>>>>>>>>>>>>> proper justification it
>>>>>>>>>>>>>>>> isn't acceptable anyway. And so far we still
>>>>>>>>>>>>>>>> don't know which problem
>>>>>>>>>>>>>>>> you actually have.
>>>>>>>>>>>>>>>> FIRST please provide the requested logs and
>>>>>>>>>>>>>>>> explain the actual problem
>>>>>>>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku
>>>>>>>>>>>>>>>> <ljakku77@gmail.com <mailto:ljakku77@gmail.com>>
>>>>>>>>>>>>>>>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On
>>>>>>>>>>>>>>>> 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300,
>>>>>>>>>>>>>>>> Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13
>>>>>>>>>>>>>>>> 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at
>>>>>>>>>>>>>>>> 01:30:13PM +0300, Lauri Jakku wrote: From
>>>>>>>>>>>>>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17
>>>>>>>>>>>>>>>> 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon,
>>>>>>>>>>>>>>>> 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET:
>>>>>>>>>>>>>>>> r8168/r8169 identifying fix The driver installation
>>>>>>>>>>>>>>>> determination made properly by checking PHY vs DRIVER
>>>>>>>>>>>>>>>> id's. --- drivers/net/ethernet/realtek/r8169_main.c |
>>>>>>>>>>>>>>>> 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c |
>>>>>>>>>>>>>>>> 11 +++- 2 files changed, 72 insertions(+), 9
>>>>>>>>>>>>>>>> deletions(-) I would say that most of the code is debug
>>>>>>>>>>>>>>>> prints. I tought that they are helpful to keep, they
>>>>>>>>>>>>>>>> are using the debug calls, so they are not visible if
>>>>>>>>>>>>>>>> user does not like those. You are missing the point of
>>>>>>>>>>>>>>>> who are your users. Users want to have working device
>>>>>>>>>>>>>>>> and the code. They don't need or like to debug their
>>>>>>>>>>>>>>>> kernel. Thanks
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-05-02 17:56 ` Lauri Jakku
@ 2020-05-02 22:48 ` Lauri Jakku
[not found] ` <5cdc7f73-b109-2a37-8473-12889506b6a9@pp.inet.fi>
1 sibling, 0 replies; 57+ messages in thread
From: Lauri Jakku @ 2020-05-02 22:48 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 2.5.2020 20.56, Lauri Jakku wrote:
> Hi,
>
> On 1.5.2020 22.12, Lauri Jakku wrote:
>> Hi,
>>
>>
>> On 19.4.2020 19.00, Heiner Kallweit wrote:
>>> On 19.04.2020 18:49, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without
>>>>>>>>>>>>>>>>> modifications --> network does not work
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel
>>>>>>>>>>>>>>>>> (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched +
>>>>>>>>>>>>>>>>> r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're
>>>>>>>>>>>>>>>> presumable affected by a known BIOS bug.
>>>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>>>>>>> In the first referenced tickets it's about the same
>>>>>>>>>>>>>>>> mainboard (with earlier BIOS version).
>>>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the
>>>>>>>>>>>>>>>> network chip / PHY correctly, it reports
>>>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver
>>>>>>>>>>>>>>>> being found.
>>>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your
>>>>>>>>>>>>>>>> problem should be gone.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now
>>>>>>>>>>>>>> testing some mutex guard for phy state and try to use it
>>>>>>>>>>>>>> as indicator
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> that attach has been done. One thing i've noticed is that
>>>>>>>>>>>>>> driver needs to be reloaded to allow traffic (ie. ping
>>>>>>>>>>>>>> works etc.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>> All that shouldn't be needed. Just check with which PHY ID
>>>>>>>>>>>>> the PHY comes up.
>>>>>>>>>>>>> And what do you mean with "it seems"? Is the option
>>>>>>>>>>>>> enabled or not?
>>>>>>>>>>>>>
>>>>>>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>>>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then
>>>>>>>>>> you have the same
>>>>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>>>>
>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>> 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>> 0000:03:00.0: MAC version: 23
>>>>>>>>>
>>>>>>>>> ....
>>>>>>>>>
>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>
>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>> 0000:02:00.0: MAC version: 23
>>>>>>>>>
>>>>>>>>> .. after module unload & load cycle:
>>>>>>>>>
>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>> 0000:02:00.0: MAC version: 23
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> it seem to be the case that the phy_id chances onetime, then
>>>>>>>>> stays the same. I'll do few shutdowns and see
>>>>>>>>>
>>>>>>>>> is there a pattern at all .. next i'm going to try how it
>>>>>>>>> behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The BIOS downgrade: I'd like to solve this without downgrading
>>>>>>>>> BIOS. If I can't, then I'll do systemd-service that
>>>>>>>>>
>>>>>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> What i've gathered samples now, there is three values for PHY ID:
>>>>>>>>
>>>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl
>>>>>>>> |grep "PHY ver"
>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0xc2077002
>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169
>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>
>>>>>>>> I dont know are those hard coded or what, and are they device
>>>>>>>> specific how much.
>>>>>>>>
>>>>>>>> i haven't coldbooted things up, that may be that something to
>>>>>>>> check do they vary how per coldboot.
>>>>>>>>
>>>>>>>>>>> I check the ID, and revert all other changes, and check how
>>>>>>>>>>> it is working after adding the PHY id to list.
>>>>>>>>>>>
>>>>>>> What i've now learned: the patch + script + journald services ->
>>>>>>> Results working network, but it is still a workaround.
>>>>>>>
>>>>>> Following patch trusts the MAC version, another thing witch could
>>>>>> help is to derive method to do 2dn pass of the probeing:
>>>>>>
>>>>>> if specific MAC version is found.
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> index acd122a88d4a..62b37a1abc24 100644
>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct
>>>>>> rtl8169_private *tp)
>>>>>> if (!tp->phydev) {
>>>>>> mdiobus_unregister(new_bus);
>>>>>> return -ENODEV;
>>>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>> - * Therefore ensure that the dedicated PHY driver
>>>>>> is loaded.
>>>>>> - */
>>>>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>> - mdiobus_unregister(new_bus);
>>>>>> - return -EUNATCH;
>>>>>> + } else {
>>>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n",
>>>>>> tp->phydev->phy_id);
>>>>>> + dev_info(&pdev->dev, "MAC version: %d\n",
>>>>>> tp->mac_version);
>>>>>> +
>>>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>> + /* Most chip versions fail with the
>>>>>> genphy driver.
>>>>>> + * Therefore ensure that the dedicated
>>>>>> PHY driver is loaded.
>>>>>> + */
>>>>>> + dev_err(&pdev->dev, "Not known MAC/PHY
>>>>>> version.\n", tp->phydev->phy_id);
>>>>>> + mdiobus_unregister(new_bus);
>>>>>> + return -EUNATCH;
>>>>>> + }
>>>>>> }
>>>>>>
>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>
>>>>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's
>>>>> updated.. and now up'n'running. There is one (WARN_ONCE) stack
>>>>> trace coming from driver, i think i tinker with it next, with
>>>>> above patch the network devices shows up and they can be configured.
>>>>>
>>>> I tought to ask first, before going to make new probe_type for
>>>> errorneus hw (propetype + retry counter) to do re-probe if
>>>> requested, N times. Or should the r8169_main.c return deferred
>>>> probe on error on some MAC enums ? Which approach is design-wise
>>>> sound ?
>>>>
>>>> I just tought that the DEFERRED probe may just do the trick i'm
>>>> looking ways to implement the re-probeing... hmm. I try the
>>>> deferred thing and check would that help.
>>>>
>>> Playing with options to work around the issue is of course a great
>>> way to
>>> learn about the kernel. However it's questionable whether a
>>> workaround in
>>> the driver is acceptable for dealing with the broken BIOS of exactly one
>>>> 10 yrs old board (for which even a userspace workaround exists).
>>
>> problem recognized: libphy-module get's unloaded for some reason
>> before r8169 driver loads -> missing lowlevel functionality -> not
>> working driver. This only occurs at 1st load of module.. seeking
>> solution.
>>
>>
>> There is [last unloaded: libphy] entries in log BEFORE r8169 is
>> probed first time.
>>
>>
>> Any clue what is responsible for unloading to occur ?
>>
>>
> Right now I'm debugging what is the reason, behind that the module
> starts to work properly only when
>
> unload & reload cycle is done.
>
>
> The libphy is listed as loaded, but the check for low level read/write
> function is not set -> r8169 modules rlt_open() fails.
>
> See here:
>
> touko 02 20:40:04 MinistryOfSillyWalk kernel: ------------[ cut here
> ]------------
> touko 02 20:40:04 MinistryOfSillyWalk kernel: read_page callback not
> available, PHY driver not loaded?
> touko 02 20:40:04 MinistryOfSillyWalk kernel: WARNING: CPU: 3 PID: 787
> at drivers/net/phy/phy-core.c:750 phy_save_page+0xb1/0xe3 [libph
> y]
> touko 02 20:40:04 MinistryOfSillyWalk kernel: Modules linked in: cmac
> algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel b
> luetooth ecdh_generic rfkill ecc uvcvideo videobuf2_vmalloc
> videobuf2_memops snd_usb_audio videobuf2_v4l2 videobuf2_common
> snd_usbmidi_
> lib videodev snd_rawmidi snd_seq_device mc input_leds joydev mousedev
> squashfs loop amdgpu snd_hda_codec_realtek gpu_sched i2c_algo_bit
> ttm snd_hda_codec_generic drm_kms_helper edac_mce_amd ledtrig_audio
> cec rc_core kvm_amd drm ccp snd_hda_codec_hdmi agpgart rng_core kv
> m snd_hda_intel syscopyarea sysfillrect ppdev sysimgblt
> snd_intel_dspcfg fb_sys_fops snd_hda_codec snd_hda_core snd_hwdep
> irqbypass wmi
> _bmof snd_pcm snd_timer snd evdev pcspkr soundcore parport_pc parport
> sp5100_tco mac_hid i2c_piix4 k10temp acpi_cpufreq uinput crypto_u
> ser ip_tables x_tables hid_generic usbhid hid ohci_pci virtio_net
> net_failover failover firewire_ohci firewire_core crc_itu_t pata_atii
> xp ehci_pci ehci_hcd sr_mod cdrom ohci_hcd ata_generic pata_acpi
> pata_jmicron wmi floppy
> touko 02 20:40:04 MinistryOfSillyWalk kernel: r8169 realtek libphy
> touko 02 20:40:04 MinistryOfSillyWalk kernel: CPU: 3 PID: 787 Comm:
> NetworkManager Not tainted 5.7.0-1-raw #12
> touko 02 20:40:04 MinistryOfSillyWalk kernel: Hardware name: Gigabyte
> Technology Co., Ltd. GA-MA790FXT-UD5P/GA-MA790FXT-UD5P, BIOS F8l
> 07/15/2010
> touko 02 20:40:04 MinistryOfSillyWalk kernel: RIP:
> 0010:phy_save_page+0xb1/0xe3 [libphy]
> touko 02 20:40:04 MinistryOfSillyWalk kernel: Code: c8 82 11 c0 e8 06
> 28 ff cc 85 db 74 47 48 8b 85 48 03 00 00 48 83 b8 68 01 00 00 00 75
> 10 48 c7 c7 e8 82 11 c0 e8 a9 dd f7 cc <0f> 0b eb 26 48 c7 c7 52 78 11
> c0 e8 99 dd f7 cc 0f 0b 48 8b 85 48
> touko 02 20:40:04 MinistryOfSillyWalk kernel: RSP:
> 0018:ffff962c408ef370 EFLAGS: 00010282
> touko 02 20:40:04 MinistryOfSillyWalk kernel: RAX: 0000000000000000
> RBX: 0000000000000001 RCX: 0000000000000000
> touko 02 20:40:04 MinistryOfSillyWalk kernel: RDX: 0000000000000001
> RSI: 0000000000000092 RDI: 00000000ffffffff
> touko 02 20:40:05 MinistryOfSillyWalk kernel: RBP: ffff8b1af3eb8800
> R08: 00000000000004b3 R09: 0000000000000004
> touko 02 20:40:05 MinistryOfSillyWalk kernel: R10: 0000000000000000
> R11: 0000000000000001 R12: 00000000ffffffa1
> touko 02 20:40:05 MinistryOfSillyWalk kernel: R13: 0000000000000002
> R14: 0000000000000002 R15: ffff8b1af3eb8800
> touko 02 20:40:05 MinistryOfSillyWalk kernel: FS:
> 00007f07be5d4d80(0000) GS:ffff8b1af7cc0000(0000) knlGS:0000000000000000
> touko 02 20:40:05 MinistryOfSillyWalk kernel: CS: 0010 DS: 0000 ES:
> 0000 CR0: 0000000080050033
> touko 02 20:40:05 MinistryOfSillyWalk kernel: CR2: 000055b83aecb008
> CR3: 00000002246b0000 CR4: 00000000000006e0
> touko 02 20:40:05 MinistryOfSillyWalk kernel: Call Trace:
> touko 02 20:40:05 MinistryOfSillyWalk kernel:
> phy_select_page+0x53/0x7a [libphy]
> touko 02 20:40:05 MinistryOfSillyWalk kernel:
> phy_write_paged+0x5c/0xa0 [libphy]
> touko 02 20:40:05 MinistryOfSillyWalk kernel:
> rtl8168d_1_hw_phy_config+0x9d/0x210 [r8169]
> touko 02 20:40:05 MinistryOfSillyWalk kernel:
> rtl8169_init_phy+0x19/0x110 [r8169]
> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl_open+0x354/0x4d0 [r8169]
> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_open+0xe0/0x170
> touko 02 20:40:05 MinistryOfSillyWalk kernel:
> __dev_change_flags+0x188/0x1e0
> touko 02 20:40:05 MinistryOfSillyWalk kernel: dev_change_flags+0x21/0x60
> touko 02 20:40:05 MinistryOfSillyWalk kernel: do_setlink+0x78a/0xfd0
>
>
> Something does not setup/register properly at first the way it should.
>
>
I think I solved it: realtek (the phy driver) was missing device entry
for the PHY ID reported by the NIC to match -> read_page and write_page
function pointers should now be set. The generic PHY does not fill the
driver's functionality to read or write pages. It happens to be so that
the drivers for RTL8211B Gigabit Ethernet seems to work just fine for my
NIC's.
I've documented current state to Manjaro's forum:
https://forum.manjaro.org/t/your-post-in-r8168-kernel-5-6-3-driver-broken/139869/3
.. after i cleanup debugs away and do speedtests.
Could the fix be something to considerate to upstream, the fix I'm
proposing is not the reload hack, but just the kernel modifications?
>>>>>>>>>>>>>>>>> The problem with old method seems to be, that device
>>>>>>>>>>>>>>>>> does not have had time to attach before the
>>>>>>>>>>>>>>>>> PHY driver check.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The patch:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int
>>>>>>>>>>>>>>>>> r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>>>>>>> /* Most chip versions fail with
>>>>>>>>>>>>>>>>> the genphy driver.
>>>>>>>>>>>>>>>>> * Therefore ensure that the
>>>>>>>>>>>>>>>>> dedicated PHY driver is loaded.
>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it
>>>>>>>>>>>>>>>>> needs to be added to initramfs?\n");
>>>>>>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>>>> return -EUNATCH;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>> b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>>>>>>>>> static int __phy_read_page(struct phy_device
>>>>>>>>>>>>>>>>> *phydev)
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page,
>>>>>>>>>>>>>>>>> "read_page callback not available, PHY driver not
>>>>>>>>>>>>>>>>> loaded?\n"))
>>>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>> @@ -712,12 +716,17 @@ static int
>>>>>>>>>>>>>>>>> __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>>>>> static int __phy_write_page(struct phy_device
>>>>>>>>>>>>>>>>> *phydev, int page)
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page,
>>>>>>>>>>>>>>>>> "write_page callback not available, PHY driver not
>>>>>>>>>>>>>>>>> loaded?\n"))
>>>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>> return phydev->drv->write_page(phydev,
>>>>>>>>>>>>>>>>> page);
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> /**
>>>>>>>>>>>>>>>>> * phy_save_page() - take the bus lock and save
>>>>>>>>>>>>>>>>> the current page
>>>>>>>>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit
>>>>>>>>>>>>>>>>> <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>>
>>>>>>>>>>>>>>>>> kirjoitti:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi, There seems to he Something odd
>>>>>>>>>>>>>>>>> problem, maybe timing related. Stripped version not
>>>>>>>>>>>>>>>>> workingas expected. I get back to you, when i have it
>>>>>>>>>>>>>>>>> working.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There's no point in working on your patch. W/o
>>>>>>>>>>>>>>>>> proper justification it
>>>>>>>>>>>>>>>>> isn't acceptable anyway. And so far we still
>>>>>>>>>>>>>>>>> don't know which problem
>>>>>>>>>>>>>>>>> you actually have.
>>>>>>>>>>>>>>>>> FIRST please provide the requested logs and
>>>>>>>>>>>>>>>>> explain the actual problem
>>>>>>>>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku
>>>>>>>>>>>>>>>>> <ljakku77@gmail.com <mailto:ljakku77@gmail.com>>
>>>>>>>>>>>>>>>>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On
>>>>>>>>>>>>>>>>> 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300,
>>>>>>>>>>>>>>>>> Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13
>>>>>>>>>>>>>>>>> 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at
>>>>>>>>>>>>>>>>> 01:30:13PM +0300, Lauri Jakku wrote: From
>>>>>>>>>>>>>>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17
>>>>>>>>>>>>>>>>> 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date:
>>>>>>>>>>>>>>>>> Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET:
>>>>>>>>>>>>>>>>> r8168/r8169 identifying fix The driver installation
>>>>>>>>>>>>>>>>> determination made properly by checking PHY vs DRIVER
>>>>>>>>>>>>>>>>> id's. --- drivers/net/ethernet/realtek/r8169_main.c |
>>>>>>>>>>>>>>>>> 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c
>>>>>>>>>>>>>>>>> | 11 +++- 2 files changed, 72 insertions(+), 9
>>>>>>>>>>>>>>>>> deletions(-) I would say that most of the code is
>>>>>>>>>>>>>>>>> debug prints. I tought that they are helpful to keep,
>>>>>>>>>>>>>>>>> they are using the debug calls, so they are not
>>>>>>>>>>>>>>>>> visible if user does not like those. You are missing
>>>>>>>>>>>>>>>>> the point of who are your users. Users want to have
>>>>>>>>>>>>>>>>> working device and the code. They don't need or like
>>>>>>>>>>>>>>>>> to debug their kernel. Thanks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
[not found] ` <5cdc7f73-b109-2a37-8473-12889506b6a9@pp.inet.fi>
@ 2020-05-02 23:15 ` Heiner Kallweit
2020-05-03 0:11 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Heiner Kallweit @ 2020-05-02 23:15 UTC (permalink / raw)
To: Lauri Jakku; +Cc: Leon Romanovsky, netdev, nic_swsd
On 03.05.2020 00:42, Lauri Jakku wrote:
> Hi,
>
>
>
> On 2.5.2020 20.56, Lauri Jakku wrote:
>> Hi,
>>
>> On 1.5.2020 22.12, Lauri Jakku wrote:
>>> Hi,
>>>
>>>
>>> On 19.4.2020 19.00, Heiner Kallweit wrote:
>>>> On 19.04.2020 18:49, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>>>>> Hi
>>>>>>>>>>>>
>>>>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>>>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>>>>>>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>>>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>>>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
>>>>>>>>>>>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>>>>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then you have the same
>>>>>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>>>>>
>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: MAC version: 23
>>>>>>>>>>
>>>>>>>>>> ....
>>>>>>>>>>
>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>
>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>>>>
>>>>>>>>>> .. after module unload & load cycle:
>>>>>>>>>>
>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> it seem to be the case that the phy_id chances onetime, then stays the same. I'll do few shutdowns and see
>>>>>>>>>>
>>>>>>>>>> is there a pattern at all .. next i'm going to try how it behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The BIOS downgrade: I'd like to solve this without downgrading BIOS. If I can't, then I'll do systemd-service that
>>>>>>>>>>
>>>>>>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> What i've gathered samples now, there is three values for PHY ID:
>>>>>>>>>
>>>>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep "PHY ver"
>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc2077002
>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>
>>>>>>>>> I dont know are those hard coded or what, and are they device specific how much.
>>>>>>>>>
>>>>>>>>> i haven't coldbooted things up, that may be that something to check do they vary how per coldboot.
>>>>>>>>>
>>>>>>>>>>>> I check the ID, and revert all other changes, and check how it is working after adding the PHY id to list.
>>>>>>>>>>>>
>>>>>>>> What i've now learned: the patch + script + journald services -> Results working network, but it is still a workaround.
>>>>>>>>
>>>>>>> Following patch trusts the MAC version, another thing witch could help is to derive method to do 2dn pass of the probeing:
>>>>>>>
>>>>>>> if specific MAC version is found.
>>>>>>>
>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> index acd122a88d4a..62b37a1abc24 100644
>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>> if (!tp->phydev) {
>>>>>>> mdiobus_unregister(new_bus);
>>>>>>> return -ENODEV;
>>>>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>> - */
>>>>>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>> - mdiobus_unregister(new_bus);
>>>>>>> - return -EUNATCH;
>>>>>>> + } else {
>>>>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>>>>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>>>>>> +
>>>>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>> + /* Most chip versions fail with the genphy driver.
>>>>>>> + * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>> + */
>>>>>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n", tp->phydev->phy_id);
>>>>>>> + mdiobus_unregister(new_bus);
>>>>>>> + return -EUNATCH;
>>>>>>> + }
>>>>>>> }
>>>>>>>
>>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>>
>>>>>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's updated.. and now up'n'running. There is one (WARN_ONCE) stack trace coming from driver, i think i tinker with it next, with above patch the network devices shows up and they can be configured.
>>>>>>
>>>>> I tought to ask first, before going to make new probe_type for errorneus hw (propetype + retry counter) to do re-probe if requested, N times. Or should the r8169_main.c return deferred probe on error on some MAC enums ? Which approach is design-wise sound ?
>>>>>
>>>>> I just tought that the DEFERRED probe may just do the trick i'm looking ways to implement the re-probeing... hmm. I try the deferred thing and check would that help.
>>>>>
>>>> Playing with options to work around the issue is of course a great way to
>>>> learn about the kernel. However it's questionable whether a workaround in
>>>> the driver is acceptable for dealing with the broken BIOS of exactly one
>>>>> 10 yrs old board (for which even a userspace workaround exists).
>>>
>>> problem recognized: libphy-module get's unloaded for some reason before r8169 driver loads -> missing lowlevel functionality -> not working driver. This only occurs at 1st load of module.. seeking solution.
>>>
>>>
>>> There is [last unloaded: libphy] entries in log BEFORE r8169 is probed first time.
>>>
>>>
>>> Any clue what is responsible for unloading to occur ?
>>>
>>>
>> Right now I'm debugging what is the reason, behind that the module starts to work properly only when
>>
>> unload & reload cycle is done.
>>
>>
>> The libphy is listed as loaded, but the check for low level read/write function is not set -> r8169 modules rlt_open() fails.
>>
>> See here:
>>
>> touko 02 20:40:04 MinistryOfSillyWalk kernel: ------------[ cut here ]------------
>> touko 02 20:40:04 MinistryOfSillyWalk kernel: read_page callback not available, PHY driver not loaded?
>> touko 02 20:40:04 MinistryOfSillyWalk kernel: WARNING: CPU: 3 PID: 787 at drivers/net/phy/phy-core.c:750 phy_save_page+0xb1/0xe3 [libph
>> y]
>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Modules linked in: cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel b
>> luetooth ecdh_generic rfkill ecc uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio videobuf2_v4l2 videobuf2_common snd_usbmidi_
>> lib videodev snd_rawmidi snd_seq_device mc input_leds joydev mousedev squashfs loop amdgpu snd_hda_codec_realtek gpu_sched i2c_algo_bit
>> ttm snd_hda_codec_generic drm_kms_helper edac_mce_amd ledtrig_audio cec rc_core kvm_amd drm ccp snd_hda_codec_hdmi agpgart rng_core kv
>> m snd_hda_intel syscopyarea sysfillrect ppdev sysimgblt snd_intel_dspcfg fb_sys_fops snd_hda_codec snd_hda_core snd_hwdep irqbypass wmi
>> _bmof snd_pcm snd_timer snd evdev pcspkr soundcore parport_pc parport sp5100_tco mac_hid i2c_piix4 k10temp acpi_cpufreq uinput crypto_u
>> ser ip_tables x_tables hid_generic usbhid hid ohci_pci virtio_net net_failover failover firewire_ohci firewire_core crc_itu_t pata_atii
>> xp ehci_pci ehci_hcd sr_mod cdrom ohci_hcd ata_generic pata_acpi pata_jmicron wmi floppy
>> touko 02 20:40:04 MinistryOfSillyWalk kernel: r8169 realtek libphy
>> touko 02 20:40:04 MinistryOfSillyWalk kernel: CPU: 3 PID: 787 Comm: NetworkManager Not tainted 5.7.0-1-raw #12
>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Hardware name: Gigabyte Technology Co., Ltd. GA-MA790FXT-UD5P/GA-MA790FXT-UD5P, BIOS F8l 07/15/2010
>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RIP: 0010:phy_save_page+0xb1/0xe3 [libphy]
>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Code: c8 82 11 c0 e8 06 28 ff cc 85 db 74 47 48 8b 85 48 03 00 00 48 83 b8 68 01 00 00 00 75 10 48 c7 c7 e8 82 11 c0 e8 a9 dd f7 cc <0f> 0b eb 26 48 c7 c7 52 78 11 c0 e8 99 dd f7 cc 0f 0b 48 8b 85 48
>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RSP: 0018:ffff962c408ef370 EFLAGS: 00010282
>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RDX: 0000000000000001 RSI: 0000000000000092 RDI: 00000000ffffffff
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: RBP: ffff8b1af3eb8800 R08: 00000000000004b3 R09: 0000000000000004
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffa1
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R13: 0000000000000002 R14: 0000000000000002 R15: ffff8b1af3eb8800
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: FS: 00007f07be5d4d80(0000) GS:ffff8b1af7cc0000(0000) knlGS:0000000000000000
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CR2: 000055b83aecb008 CR3: 00000002246b0000 CR4: 00000000000006e0
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: Call Trace:
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: phy_select_page+0x53/0x7a [libphy]
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: phy_write_paged+0x5c/0xa0 [libphy]
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl8168d_1_hw_phy_config+0x9d/0x210 [r8169]
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl8169_init_phy+0x19/0x110 [r8169]
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl_open+0x354/0x4d0 [r8169]
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_open+0xe0/0x170
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_change_flags+0x188/0x1e0
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: dev_change_flags+0x21/0x60
>> touko 02 20:40:05 MinistryOfSillyWalk kernel: do_setlink+0x78a/0xfd0
>>
>>
>> Something does not setup/register properly at first the way it should.
>>
>>
>
> I think i solved it: realtek (the phy driver) was missing device entry for the PHY ID reported by the NIC to match -> read_page and write_page function pointers should now be set. The generic PHY does not fill
>
> the driver's functionality to read or write pages. It happens to be so that the drivers for |RTL8211B Gigabit Ethernet seems to work just fine for my NIC's.
The analysis is wrong. The incorrect PHY ID is not root cause of the
problem, it's caused by a BIOS bug. It's not a valid PHY ID. If you want
to do something, then you could try to inject a PHY soft reset before
the MII bus is registered. This should be board-specific, e.g. using
dmi_check_system().
> |
>
> |
> |
>
> |I've documented current state to Manjaro's forum: https://forum.manjaro.org/t/your-post-in-r8168-kernel-5-6-3-driver-broken/139869/3 .. after i cleanup debugs away and do speedtests. Could the fix be something to considerate to upstream ?|
>
> |
> |
>
> |The fix I'm proposing is not the reload hack, but just kernel modifications.
> |
>
>
>>>>>>>>>>>>>>>>>> The problem with old method seems to be, that device does not have had time to attach before the
>>>>>>>>>>>>>>>>>> PHY driver check.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The patch:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>>>>>>>> /* Most chip versions fail with the genphy driver.
>>>>>>>>>>>>>>>>>> * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>>>>> return -EUNATCH;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>>>>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>>>>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> /**
>>>>>>>>>>>>>>>>>> * phy_save_page() - take the bus lock and save the current page
>>>>>>>>>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi, There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> There's no point in working on your patch. W/o proper justification it
>>>>>>>>>>>>>>>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>>>>>>>>>>>>>>>> you actually have.
>>>>>>>>>>>>>>>>>> FIRST please provide the requested logs and explain the actual problem
>>>>>>>>>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver installation determination made properly by checking PHY vs DRIVER id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files changed, 72 insertions(+), 9 deletions(-) I would say that most of the code is debug prints. I tought that they are helpful to keep, they are using the debug calls, so they are not visible if user does not like those. You are missing the point of who are your users. Users want to have working device and the code. They don't need or like to debug their kernel. Thanks
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-05-02 23:15 ` Heiner Kallweit
@ 2020-05-03 0:11 ` Lauri Jakku
2020-05-03 1:34 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-05-03 0:11 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
On 3.5.2020 2.15, Heiner Kallweit wrote:
> On 03.05.2020 00:42, Lauri Jakku wrote:
>> Hi,
>>
>>
>>
>> On 2.5.2020 20.56, Lauri Jakku wrote:
>>> Hi,
>>>
>>> On 1.5.2020 22.12, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>>
>>>> On 19.4.2020 19.00, Heiner Kallweit wrote:
>>>>> On 19.04.2020 18:49, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>>>>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>>>>>>>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>>>>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>>>>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
>>>>>>>>>>>>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>>>>>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then you have the same
>>>>>>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>>>>>>
>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: MAC version: 23
>>>>>>>>>>>
>>>>>>>>>>> ....
>>>>>>>>>>>
>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>
>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>>>>>
>>>>>>>>>>> .. after module unload & load cycle:
>>>>>>>>>>>
>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> it seem to be the case that the phy_id chances onetime, then stays the same. I'll do few shutdowns and see
>>>>>>>>>>>
>>>>>>>>>>> is there a pattern at all .. next i'm going to try how it behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The BIOS downgrade: I'd like to solve this without downgrading BIOS. If I can't, then I'll do systemd-service that
>>>>>>>>>>>
>>>>>>>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> What i've gathered samples now, there is three values for PHY ID:
>>>>>>>>>>
>>>>>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep "PHY ver"
>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc2077002
>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>
>>>>>>>>>> I dont know are those hard coded or what, and are they device specific how much.
>>>>>>>>>>
>>>>>>>>>> i haven't coldbooted things up, that may be that something to check do they vary how per coldboot.
>>>>>>>>>>
>>>>>>>>>>>>> I check the ID, and revert all other changes, and check how it is working after adding the PHY id to list.
>>>>>>>>>>>>>
>>>>>>>>> What i've now learned: the patch + script + journald services -> Results working network, but it is still a workaround.
>>>>>>>>>
>>>>>>>> Following patch trusts the MAC version, another thing witch could help is to derive method to do 2dn pass of the probeing:
>>>>>>>>
>>>>>>>> if specific MAC version is found.
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>> index acd122a88d4a..62b37a1abc24 100644
>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>> if (!tp->phydev) {
>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>> return -ENODEV;
>>>>>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>> - */
>>>>>>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>> - mdiobus_unregister(new_bus);
>>>>>>>> - return -EUNATCH;
>>>>>>>> + } else {
>>>>>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>>>>>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>>>>>>> +
>>>>>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>> + /* Most chip versions fail with the genphy driver.
>>>>>>>> + * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>> + */
>>>>>>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n", tp->phydev->phy_id);
>>>>>>>> + mdiobus_unregister(new_bus);
>>>>>>>> + return -EUNATCH;
>>>>>>>> + }
>>>>>>>> }
>>>>>>>>
>>>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>>>
>>>>>>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's updated.. and now up'n'running. There is one (WARN_ONCE) stack trace coming from driver, i think i tinker with it next, with above patch the network devices shows up and they can be configured.
>>>>>>>
>>>>>> I tought to ask first, before going to make new probe_type for errorneus hw (propetype + retry counter) to do re-probe if requested, N times. Or should the r8169_main.c return deferred probe on error on some MAC enums ? Which approach is design-wise sound ?
>>>>>>
>>>>>> I just tought that the DEFERRED probe may just do the trick i'm looking ways to implement the re-probeing... hmm. I try the deferred thing and check would that help.
>>>>>>
>>>>> Playing with options to work around the issue is of course a great way to
>>>>> learn about the kernel. However it's questionable whether a workaround in
>>>>> the driver is acceptable for dealing with the broken BIOS of exactly one
>>>>>> 10 yrs old board (for which even a userspace workaround exists).
>>>> problem recognized: libphy-module get's unloaded for some reason before r8169 driver loads -> missing lowlevel functionality -> not working driver. This only occurs at 1st load of module.. seeking solution.
>>>>
>>>>
>>>> There is [last unloaded: libphy] entries in log BEFORE r8169 is probed first time.
>>>>
>>>>
>>>> Any clue what is responsible for unloading to occur ?
>>>>
>>>>
>>> Right now I'm debugging what is the reason, behind that the module starts to work properly only when
>>>
>>> unload & reload cycle is done.
>>>
>>>
>>> The libphy is listed as loaded, but the check for low level read/write function is not set -> r8169 modules rlt_open() fails.
>>>
>>> See here:
>>>
>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: ------------[ cut here ]------------
>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: read_page callback not available, PHY driver not loaded?
>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: WARNING: CPU: 3 PID: 787 at drivers/net/phy/phy-core.c:750 phy_save_page+0xb1/0xe3 [libph
>>> y]
>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Modules linked in: cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel b
>>> luetooth ecdh_generic rfkill ecc uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio videobuf2_v4l2 videobuf2_common snd_usbmidi_
>>> lib videodev snd_rawmidi snd_seq_device mc input_leds joydev mousedev squashfs loop amdgpu snd_hda_codec_realtek gpu_sched i2c_algo_bit
>>> ttm snd_hda_codec_generic drm_kms_helper edac_mce_amd ledtrig_audio cec rc_core kvm_amd drm ccp snd_hda_codec_hdmi agpgart rng_core kv
>>> m snd_hda_intel syscopyarea sysfillrect ppdev sysimgblt snd_intel_dspcfg fb_sys_fops snd_hda_codec snd_hda_core snd_hwdep irqbypass wmi
>>> _bmof snd_pcm snd_timer snd evdev pcspkr soundcore parport_pc parport sp5100_tco mac_hid i2c_piix4 k10temp acpi_cpufreq uinput crypto_u
>>> ser ip_tables x_tables hid_generic usbhid hid ohci_pci virtio_net net_failover failover firewire_ohci firewire_core crc_itu_t pata_atii
>>> xp ehci_pci ehci_hcd sr_mod cdrom ohci_hcd ata_generic pata_acpi pata_jmicron wmi floppy
>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: r8169 realtek libphy
>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: CPU: 3 PID: 787 Comm: NetworkManager Not tainted 5.7.0-1-raw #12
>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Hardware name: Gigabyte Technology Co., Ltd. GA-MA790FXT-UD5P/GA-MA790FXT-UD5P, BIOS F8l 07/15/2010
>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RIP: 0010:phy_save_page+0xb1/0xe3 [libphy]
>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Code: c8 82 11 c0 e8 06 28 ff cc 85 db 74 47 48 8b 85 48 03 00 00 48 83 b8 68 01 00 00 00 75 10 48 c7 c7 e8 82 11 c0 e8 a9 dd f7 cc <0f> 0b eb 26 48 c7 c7 52 78 11 c0 e8 99 dd f7 cc 0f 0b 48 8b 85 48
>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RSP: 0018:ffff962c408ef370 EFLAGS: 00010282
>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RDX: 0000000000000001 RSI: 0000000000000092 RDI: 00000000ffffffff
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: RBP: ffff8b1af3eb8800 R08: 00000000000004b3 R09: 0000000000000004
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffa1
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R13: 0000000000000002 R14: 0000000000000002 R15: ffff8b1af3eb8800
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: FS: 00007f07be5d4d80(0000) GS:ffff8b1af7cc0000(0000) knlGS:0000000000000000
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CR2: 000055b83aecb008 CR3: 00000002246b0000 CR4: 00000000000006e0
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: Call Trace:
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: phy_select_page+0x53/0x7a [libphy]
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: phy_write_paged+0x5c/0xa0 [libphy]
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl8168d_1_hw_phy_config+0x9d/0x210 [r8169]
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl8169_init_phy+0x19/0x110 [r8169]
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl_open+0x354/0x4d0 [r8169]
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_open+0xe0/0x170
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_change_flags+0x188/0x1e0
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: dev_change_flags+0x21/0x60
>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: do_setlink+0x78a/0xfd0
>>>
>>>
>>> Something does not setup/register properly at first the way it should.
>>>
>>>
>> I think i solved it: realtek (the phy driver) was missing device entry for the PHY ID reported by the NIC to match -> read_page and write_page function pointers should now be set. The generic PHY does not fill
>>
>> the driver's functionality to read or write pages. It happens to be so that the drivers for |RTL8211B Gigabit Ethernet seems to work just fine for my NIC's.
> The analysis is wrong. The incorrect PHY ID is not root cause of the
> problem, it's caused by a BIOS bug. It's not a valid PHY ID. If you want
> to do something, then you could try to inject a PHY soft reset before
> the MII bus is registered. This should be board-specific, e.g. using
> dmi_check_system().
Ok, i'll try that approach, thanks for the tip. Hmm, I'll do similar
function mapping what the HW init/config function does determine
function to use.
I'll get back to you when I got something new developed.
>> |
>>
>> |
>> |
>>
>> |I've documented current state to Manjaro's forum: https://forum.manjaro.org/t/your-post-in-r8168-kernel-5-6-3-driver-broken/139869/3 .. after i cleanup debugs away and do speedtests. Could the fix be something to considerate to upstream ?|
>>
>> |
>> |
>>
>> |The fix I'm proposing is not the reload hack, but just kernel modifications.
>> |
>>
>>
>>>>>>>>>>>>>>>>>>> The problem with old method seems to be, that device does not have had time to attach before the
>>>>>>>>>>>>>>>>>>> PHY driver check.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The patch:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>>>>>>>>>>> + } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>>>>>>>>> /* Most chip versions fail with the genphy driver.
>>>>>>>>>>>>>>>>>>> * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>>>>>>>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>>>>>> return -EUNATCH;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>>>> @@ -704,6 +704,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>>>>>>>>>>> static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>>>> @@ -712,12 +716,17 @@ static int __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>>>>>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>>>> return phydev->drv->write_page(phydev, page);
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>> /**
>>>>>>>>>>>>>>>>>>> * phy_save_page() - take the bus lock and save the current page
>>>>>>>>>>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi, There seems to he Something odd problem, maybe timing related. Stripped version not workingas expected. I get back to you, when i have it working.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> There's no point in working on your patch. W/o proper justification it
>>>>>>>>>>>>>>>>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>>>>>>>>>>>>>>>>> you actually have.
>>>>>>>>>>>>>>>>>>> FIRST please provide the requested logs and explain the actual problem
>>>>>>>>>>>>>>>>>>> (incl. the commit that caused the regression).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi, Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix The driver installation determination made properly by checking PHY vs DRIVER id's. --- drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2 files changed, 72 insertions(+), 9 deletions(-) I would say that most of the code is debug prints. I tought that they are helpful to keep, they are using the debug calls, so they are not visible if user does not like those. You are missing the point of who are your users. Users want to have working device and the code. They don't need or like to debug their kernel. Thanks
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-05-03 0:11 ` Lauri Jakku
@ 2020-05-03 1:34 ` Lauri Jakku
2020-05-03 2:28 ` Lauri Jakku
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-05-03 1:34 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 3.5.2020 3.11, Lauri Jakku wrote:
>
> On 3.5.2020 2.15, Heiner Kallweit wrote:
>> On 03.05.2020 00:42, Lauri Jakku wrote:
>>> Hi,
>>>
>>>
>>>
>>> On 2.5.2020 20.56, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>> On 1.5.2020 22.12, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> On 19.4.2020 19.00, Heiner Kallweit wrote:
>>>>>> On 19.04.2020 18:49, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without
>>>>>>>>>>>>>>>>>>>> modifications --> network does not work
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified
>>>>>>>>>>>>>>>>>>>> kernel (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched +
>>>>>>>>>>>>>>>>>>>> r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're
>>>>>>>>>>>>>>>>>>> presumable affected by a known BIOS bug.
>>>>>>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at
>>>>>>>>>>>>>>>>>>> bugzilla.kernel.org.
>>>>>>>>>>>>>>>>>>> In the first referenced tickets it's about the same
>>>>>>>>>>>>>>>>>>> mainboard (with earlier BIOS version).
>>>>>>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the
>>>>>>>>>>>>>>>>>>> network chip / PHY correctly, it reports
>>>>>>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY
>>>>>>>>>>>>>>>>>>> driver being found.
>>>>>>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your
>>>>>>>>>>>>>>>>>>> problem should be gone.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now
>>>>>>>>>>>>>>>>> testing some mutex guard for phy state and try to use
>>>>>>>>>>>>>>>>> it as indicator
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> that attach has been done. One thing i've noticed is
>>>>>>>>>>>>>>>>> that driver needs to be reloaded to allow traffic (ie.
>>>>>>>>>>>>>>>>> ping works etc.)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All that shouldn't be needed. Just check with which PHY
>>>>>>>>>>>>>>>> ID the PHY comes up.
>>>>>>>>>>>>>>>> And what do you mean with "it seems"? Is the option
>>>>>>>>>>>>>>>> enabled or not?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I do have ROM's enabled, and it does not help with my
>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>> Your BIOS is a beta version, downgrading to F7 may help.
>>>>>>>>>>>>> Then you have the same
>>>>>>>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>>>>>>>
>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:03:00.0: MAC version: 23
>>>>>>>>>>>>
>>>>>>>>>>>> ....
>>>>>>>>>>>>
>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>
>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: MAC version: 23
>>>>>>>>>>>>
>>>>>>>>>>>> .. after module unload & load cycle:
>>>>>>>>>>>>
>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: MAC version: 23
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> it seem to be the case that the phy_id chances onetime,
>>>>>>>>>>>> then stays the same. I'll do few shutdowns and see
>>>>>>>>>>>>
>>>>>>>>>>>> is there a pattern at all .. next i'm going to try how it
>>>>>>>>>>>> behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The BIOS downgrade: I'd like to solve this without
>>>>>>>>>>>> downgrading BIOS. If I can't, then I'll do systemd-service
>>>>>>>>>>>> that
>>>>>>>>>>>>
>>>>>>>>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> What i've gathered samples now, there is three values for
>>>>>>>>>>> PHY ID:
>>>>>>>>>>>
>>>>>>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl
>>>>>>>>>>> |grep "PHY ver"
>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:02:00.0: PHY version: 0xc2077002
>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>
>>>>>>>>>>> I dont know are those hard coded or what, and are they
>>>>>>>>>>> device specific how much.
>>>>>>>>>>>
>>>>>>>>>>> i haven't coldbooted things up, that may be that something
>>>>>>>>>>> to check do they vary how per coldboot.
>>>>>>>>>>>
>>>>>>>>>>>>>> I check the ID, and revert all other changes, and check
>>>>>>>>>>>>>> how it is working after adding the PHY id to list.
>>>>>>>>>>>>>>
>>>>>>>>>> What i've now learned: the patch + script + journald services
>>>>>>>>>> -> Results working network, but it is still a workaround.
>>>>>>>>>>
>>>>>>>>> Following patch trusts the MAC version, another thing witch
>>>>>>>>> could help is to derive method to do 2dn pass of the probeing:
>>>>>>>>>
>>>>>>>>> if specific MAC version is found.
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>> index acd122a88d4a..62b37a1abc24 100644
>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct
>>>>>>>>> rtl8169_private *tp)
>>>>>>>>> if (!tp->phydev) {
>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>> return -ENODEV;
>>>>>>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>> - /* Most chip versions fail with the genphy
>>>>>>>>> driver.
>>>>>>>>> - * Therefore ensure that the dedicated PHY
>>>>>>>>> driver is loaded.
>>>>>>>>> - */
>>>>>>>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>> - mdiobus_unregister(new_bus);
>>>>>>>>> - return -EUNATCH;
>>>>>>>>> + } else {
>>>>>>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n",
>>>>>>>>> tp->phydev->phy_id);
>>>>>>>>> + dev_info(&pdev->dev, "MAC version: %d\n",
>>>>>>>>> tp->mac_version);
>>>>>>>>> +
>>>>>>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>> + /* Most chip versions fail with the
>>>>>>>>> genphy driver.
>>>>>>>>> + * Therefore ensure that the dedicated
>>>>>>>>> PHY driver is loaded.
>>>>>>>>> + */
>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC/PHY
>>>>>>>>> version.\n", tp->phydev->phy_id);
>>>>>>>>> + mdiobus_unregister(new_bus);
>>>>>>>>> + return -EUNATCH;
>>>>>>>>> + }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>>>>
>>>>>>>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's
>>>>>>>> updated.. and now up'n'running. There is one (WARN_ONCE) stack
>>>>>>>> trace coming from driver, i think i tinker with it next, with
>>>>>>>> above patch the network devices shows up and they can be
>>>>>>>> configured.
>>>>>>>>
>>>>>>> I tought to ask first, before going to make new probe_type for
>>>>>>> errorneus hw (propetype + retry counter) to do re-probe if
>>>>>>> requested, N times. Or should the r8169_main.c return deferred
>>>>>>> probe on error on some MAC enums ? Which approach is design-wise
>>>>>>> sound ?
>>>>>>>
>>>>>>> I just tought that the DEFERRED probe may just do the trick i'm
>>>>>>> looking ways to implement the re-probeing... hmm. I try the
>>>>>>> deferred thing and check would that help.
>>>>>>>
>>>>>> Playing with options to work around the issue is of course a
>>>>>> great way to
>>>>>> learn about the kernel. However it's questionable whether a
>>>>>> workaround in
>>>>>> the driver is acceptable for dealing with the broken BIOS of
>>>>>> exactly one
>>>>>>> 10 yrs old board (for which even a userspace workaround exists).
>>>>> problem recognized: libphy-module get's unloaded for some reason
>>>>> before r8169 driver loads -> missing lowlevel functionality -> not
>>>>> working driver. This only occurs at 1st load of module.. seeking
>>>>> solution.
>>>>>
>>>>>
>>>>> There is [last unloaded: libphy] entries in log BEFORE r8169 is
>>>>> probed first time.
>>>>>
>>>>>
>>>>> Any clue what is responsible for unloading to occur ?
>>>>>
>>>>>
>>>> Right now I'm debugging what is the reason, behind that the module
>>>> starts to work properly only when
>>>>
>>>> unload & reload cycle is done.
>>>>
>>>>
>>>> The libphy is listed as loaded, but the check for low level
>>>> read/write function is not set -> r8169 modules rlt_open() fails.
>>>>
>>>> See here:
>>>>
>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: ------------[ cut
>>>> here ]------------
>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: read_page callback
>>>> not available, PHY driver not loaded?
>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: WARNING: CPU: 3 PID:
>>>> 787 at drivers/net/phy/phy-core.c:750 phy_save_page+0xb1/0xe3 [libph
>>>> y]
>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Modules linked in:
>>>> cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel b
>>>> luetooth ecdh_generic rfkill ecc uvcvideo videobuf2_vmalloc
>>>> videobuf2_memops snd_usb_audio videobuf2_v4l2 videobuf2_common
>>>> snd_usbmidi_
>>>> lib videodev snd_rawmidi snd_seq_device mc input_leds joydev
>>>> mousedev squashfs loop amdgpu snd_hda_codec_realtek gpu_sched
>>>> i2c_algo_bit
>>>> ttm snd_hda_codec_generic drm_kms_helper edac_mce_amd
>>>> ledtrig_audio cec rc_core kvm_amd drm ccp snd_hda_codec_hdmi
>>>> agpgart rng_core kv
>>>> m snd_hda_intel syscopyarea sysfillrect ppdev sysimgblt
>>>> snd_intel_dspcfg fb_sys_fops snd_hda_codec snd_hda_core snd_hwdep
>>>> irqbypass wmi
>>>> _bmof snd_pcm snd_timer snd evdev pcspkr soundcore parport_pc
>>>> parport sp5100_tco mac_hid i2c_piix4 k10temp acpi_cpufreq uinput
>>>> crypto_u
>>>> ser ip_tables x_tables hid_generic usbhid hid ohci_pci virtio_net
>>>> net_failover failover firewire_ohci firewire_core crc_itu_t pata_atii
>>>> xp ehci_pci ehci_hcd sr_mod cdrom ohci_hcd ata_generic pata_acpi
>>>> pata_jmicron wmi floppy
>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: r8169 realtek libphy
>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: CPU: 3 PID: 787 Comm:
>>>> NetworkManager Not tainted 5.7.0-1-raw #12
>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Hardware name:
>>>> Gigabyte Technology Co., Ltd. GA-MA790FXT-UD5P/GA-MA790FXT-UD5P,
>>>> BIOS F8l 07/15/2010
>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RIP:
>>>> 0010:phy_save_page+0xb1/0xe3 [libphy]
>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Code: c8 82 11 c0 e8
>>>> 06 28 ff cc 85 db 74 47 48 8b 85 48 03 00 00 48 83 b8 68 01 00 00
>>>> 00 75 10 48 c7 c7 e8 82 11 c0 e8 a9 dd f7 cc <0f> 0b eb 26 48 c7 c7
>>>> 52 78 11 c0 e8 99 dd f7 cc 0f 0b 48 8b 85 48
>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RSP:
>>>> 0018:ffff962c408ef370 EFLAGS: 00010282
>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RAX: 0000000000000000
>>>> RBX: 0000000000000001 RCX: 0000000000000000
>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RDX: 0000000000000001
>>>> RSI: 0000000000000092 RDI: 00000000ffffffff
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: RBP: ffff8b1af3eb8800
>>>> R08: 00000000000004b3 R09: 0000000000000004
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R10: 0000000000000000
>>>> R11: 0000000000000001 R12: 00000000ffffffa1
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R13: 0000000000000002
>>>> R14: 0000000000000002 R15: ffff8b1af3eb8800
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: FS:
>>>> 00007f07be5d4d80(0000) GS:ffff8b1af7cc0000(0000)
>>>> knlGS:0000000000000000
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CS: 0010 DS: 0000
>>>> ES: 0000 CR0: 0000000080050033
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CR2: 000055b83aecb008
>>>> CR3: 00000002246b0000 CR4: 00000000000006e0
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: Call Trace:
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>> phy_select_page+0x53/0x7a [libphy]
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>> phy_write_paged+0x5c/0xa0 [libphy]
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>> rtl8168d_1_hw_phy_config+0x9d/0x210 [r8169]
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>> rtl8169_init_phy+0x19/0x110 [r8169]
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl_open+0x354/0x4d0
>>>> [r8169]
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_open+0xe0/0x170
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>> __dev_change_flags+0x188/0x1e0
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>> dev_change_flags+0x21/0x60
>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: do_setlink+0x78a/0xfd0
>>>>
>>>>
>>>> Something does not setup/register properly at first the way it should.
>>>>
>>>>
>>> I think i solved it: realtek (the phy driver) was missing device
>>> entry for the PHY ID reported by the NIC to match -> read_page and
>>> write_page function pointers should now be set. The generic PHY does
>>> not fill
>>>
>>> the driver's functionality to read or write pages. It happens to be
>>> so that the drivers for |RTL8211B Gigabit Ethernet seems to work
>>> just fine for my NIC's.
>> The analysis is wrong. The incorrect PHY ID is not root cause of the
>> problem, it's caused by a BIOS bug. It's not a valid PHY ID. If you want
>> to do something, then you could try to inject a PHY soft reset before
>> the MII bus is registered. This should be board-specific, e.g. using
>> dmi_check_system().
>
> Ok, i'll try that approach, thanks for the tip. Hmm, I'll do similar
> function mapping what the HW init/config function does determine
>
> function to use.
>
>
> I'll get back to you when I got something new developed.
>
Oujeah, now it works OK.. the soft reset was all it needed.
Here's the patch:
From 06c5deacf3ca9f9258431756a41ff0ba1792f1f7 Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Thu, 16 Apr 2020 00:38:51 +0300
Subject: [PATCH] NET: r8169 driver identifying improvement.
Trust device MAC enum + r8169d NIC soft reset
before configuration.
This commit adds enumeration check and allows
driver to be slow to attach.
Signed-off-by: Lauri Jakku <lja@iki.fi>
---
drivers/net/ethernet/realtek/r8169_main.c | 24 +++--
.../net/ethernet/realtek/r8169_phy_config.c | 80 ++++++++++++++++
drivers/net/phy/phy-core.c | 91 ++++++++++++++++++-
3 files changed, 182 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..a85764f6e448 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -640,7 +640,6 @@ MODULE_AUTHOR("Realtek and the Linux r8169 crew
<netdev@vger.kernel.org>");
MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
module_param_named(debug, debug.msg_enable, int, 0);
MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
-MODULE_SOFTDEP("pre: realtek");
MODULE_LICENSE("GPL");
MODULE_FIRMWARE(FIRMWARE_8168D_1);
MODULE_FIRMWARE(FIRMWARE_8168D_2);
@@ -5172,13 +5171,18 @@ static int r8169_mdio_register(struct
rtl8169_private *tp)
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to
be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
+ dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
+
+ if (tp->mac_version == RTL_GIGA_MAC_NONE) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver is loaded.
+ */
+ dev_err(&pdev->dev, "Not known MAC/PHY version.\n");
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
@@ -5513,6 +5517,9 @@ static int rtl_init_one(struct pci_dev *pdev,
const struct pci_device_id *ent)
rtl_chip_infos[chipset].name, dev->dev_addr, xid,
pci_irq_vector(pdev, 0));
+ dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
+ dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
+
if (jumbo_max)
netif_info(tp, probe, dev,
"jumbo features [frames: %d bytes, tx checksumming: %s]\n",
@@ -5532,6 +5539,7 @@ static int rtl_init_one(struct pci_dev *pdev,
const struct pci_device_id *ent)
return rc;
}
+
static struct pci_driver rtl8169_pci_driver = {
.name = MODULENAME,
.id_table = rtl8169_pci_tbl,
diff --git a/drivers/net/ethernet/realtek/r8169_phy_config.c
b/drivers/net/ethernet/realtek/r8169_phy_config.c
index b73f7d023e99..73d604c7a8a8 100644
--- a/drivers/net/ethernet/realtek/r8169_phy_config.c
+++ b/drivers/net/ethernet/realtek/r8169_phy_config.c
@@ -1243,6 +1243,84 @@ static void rtl8125_2_hw_phy_config(struct
rtl8169_private *tp,
rtl8125_config_eee_phy(phydev);
}
+
+static void rtl8168d_hw_phy_pre_config_actions(struct rtl8169_private *tp,
+ struct phy_device *phydev)
+{
+ /* Reset the PHY before configuration. There is BIOS bug that gives
+ * random PHY ID when device is not soft resetted first. --lja
+ */
+ genphy_soft_reset(phydev);
+}
+
+
+
+void r8169_hw_phy_pre_config_actions(struct rtl8169_private *tp, struct
phy_device *phydev,
+ enum mac_version ver)
+{
+ static const rtl_phy_cfg_fct phy_pre_config_actions[] = {
+ /* PCI devices. */
+ [RTL_GIGA_MAC_VER_02] = NULL,
+ [RTL_GIGA_MAC_VER_03] = NULL,
+ [RTL_GIGA_MAC_VER_04] = NULL,
+ [RTL_GIGA_MAC_VER_05] = NULL,
+ [RTL_GIGA_MAC_VER_06] = NULL,
+ /* PCI-E devices. */
+ [RTL_GIGA_MAC_VER_07] = NULL,
+ [RTL_GIGA_MAC_VER_08] = NULL,
+ [RTL_GIGA_MAC_VER_09] = NULL,
+ [RTL_GIGA_MAC_VER_10] = NULL,
+ [RTL_GIGA_MAC_VER_11] = NULL,
+ [RTL_GIGA_MAC_VER_12] = NULL,
+ [RTL_GIGA_MAC_VER_13] = NULL,
+ [RTL_GIGA_MAC_VER_14] = NULL,
+ [RTL_GIGA_MAC_VER_15] = NULL,
+ [RTL_GIGA_MAC_VER_16] = NULL,
+ [RTL_GIGA_MAC_VER_17] = NULL,
+ [RTL_GIGA_MAC_VER_18] = NULL,
+ [RTL_GIGA_MAC_VER_19] = NULL,
+ [RTL_GIGA_MAC_VER_20] = NULL,
+ [RTL_GIGA_MAC_VER_21] = NULL,
+ [RTL_GIGA_MAC_VER_22] = NULL,
+ [RTL_GIGA_MAC_VER_23] = NULL,
+ [RTL_GIGA_MAC_VER_24] = NULL,
+ [RTL_GIGA_MAC_VER_25] = rtl8168d_hw_phy_pre_config_actions,
+ [RTL_GIGA_MAC_VER_26] = rtl8168d_hw_phy_pre_config_actions,
+ [RTL_GIGA_MAC_VER_27] = rtl8168d_hw_phy_pre_config_actions,
+ [RTL_GIGA_MAC_VER_28] = rtl8168d_hw_phy_pre_config_actions,
+ [RTL_GIGA_MAC_VER_29] = NULL,
+ [RTL_GIGA_MAC_VER_30] = NULL,
+ [RTL_GIGA_MAC_VER_31] = NULL,
+ [RTL_GIGA_MAC_VER_32] = NULL,
+ [RTL_GIGA_MAC_VER_33] = NULL,
+ [RTL_GIGA_MAC_VER_34] = NULL,
+ [RTL_GIGA_MAC_VER_35] = NULL,
+ [RTL_GIGA_MAC_VER_36] = NULL,
+ [RTL_GIGA_MAC_VER_37] = NULL,
+ [RTL_GIGA_MAC_VER_38] = NULL,
+ [RTL_GIGA_MAC_VER_39] = NULL,
+ [RTL_GIGA_MAC_VER_40] = NULL,
+ [RTL_GIGA_MAC_VER_41] = NULL,
+ [RTL_GIGA_MAC_VER_42] = NULL,
+ [RTL_GIGA_MAC_VER_43] = NULL,
+ [RTL_GIGA_MAC_VER_44] = NULL,
+ [RTL_GIGA_MAC_VER_45] = NULL,
+ [RTL_GIGA_MAC_VER_46] = NULL,
+ [RTL_GIGA_MAC_VER_47] = NULL,
+ [RTL_GIGA_MAC_VER_48] = NULL,
+ [RTL_GIGA_MAC_VER_49] = NULL,
+ [RTL_GIGA_MAC_VER_50] = NULL,
+ [RTL_GIGA_MAC_VER_51] = NULL,
+ [RTL_GIGA_MAC_VER_52] = NULL,
+ [RTL_GIGA_MAC_VER_60] = NULL,
+ [RTL_GIGA_MAC_VER_61] = NULL,
+ };
+
+ if (phy_pre_config_actions[ver])
+ phy_pre_config_actions[ver](tp, phydev);
+}
+
+
void r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device
*phydev,
enum mac_version ver)
{
@@ -1303,6 +1381,8 @@ void r8169_hw_phy_config(struct rtl8169_private
*tp, struct phy_device *phydev,
[RTL_GIGA_MAC_VER_60] = rtl8125_1_hw_phy_config,
[RTL_GIGA_MAC_VER_61] = rtl8125_2_hw_phy_config,
};
+
+ r8169_hw_phy_pre_config_actions(tp, phydev);
if (phy_configs[ver])
phy_configs[ver](tp, phydev);
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index 66b8c61ca74c..b170185a1ed1 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -151,6 +151,25 @@ static const struct phy_setting settings[] = {
};
#undef PHY_SETTING
+#ifdef DEBUG
+#define R8169_ATTACHED_PRINTK \
+ printk("Phy is attached check %s @ %d: %d\n", \
+ __FUNC__, __LINE__, is_attached_check);
+
+#else
+#define R8169_ATTACHED_PRINTK
+#endif
+
+#define PHY_NOT_ATTACHED_CHECK \
+ { \
+ void *attached_dev_ptr = (phydev) ? phydev->attached_dev : NULL; \
+ int is_attached_check = (attached_dev_ptr != NULL) && \
+ ((phydev) && (phydev->state >=
PHY_READY)); \
+ R8169_ATTACHED_PRINTK \
+ if (! is_attached_check ) return -EOPNOTSUPP; \
+ };
+
+
/**
* phy_lookup_setting - lookup a PHY setting
* @speed: speed to match
@@ -457,6 +476,9 @@ int phy_read_mmd(struct phy_device *phydev, int
devad, u32 regnum)
{
int ret;
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
phy_lock_mdio_bus(phydev);
ret = __phy_read_mmd(phydev, devad, regnum);
phy_unlock_mdio_bus(phydev);
@@ -479,6 +501,9 @@ int __phy_write_mmd(struct phy_device *phydev, int
devad, u32 regnum, u16 val)
{
int ret;
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
if (regnum > (u16)~0 || devad > 32)
return -EINVAL;
@@ -518,6 +543,9 @@ int phy_write_mmd(struct phy_device *phydev, int
devad, u32 regnum, u16 val)
{
int ret;
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
phy_lock_mdio_bus(phydev);
ret = __phy_write_mmd(phydev, devad, regnum, val);
phy_unlock_mdio_bus(phydev);
@@ -543,6 +571,10 @@ int phy_modify_changed(struct phy_device *phydev,
u32 regnum, u16 mask, u16 set)
{
int ret;
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
+
phy_lock_mdio_bus(phydev);
ret = __phy_modify_changed(phydev, regnum, mask, set);
phy_unlock_mdio_bus(phydev);
@@ -587,6 +619,9 @@ int phy_modify(struct phy_device *phydev, u32
regnum, u16 mask, u16 set)
{
int ret;
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
phy_lock_mdio_bus(phydev);
ret = __phy_modify(phydev, regnum, mask, set);
phy_unlock_mdio_bus(phydev);
@@ -613,6 +648,9 @@ int __phy_modify_mmd_changed(struct phy_device
*phydev, int devad, u32 regnum,
{
int new, ret;
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
ret = __phy_read_mmd(phydev, devad, regnum);
if (ret < 0)
return ret;
@@ -646,6 +684,10 @@ int phy_modify_mmd_changed(struct phy_device
*phydev, int devad, u32 regnum,
{
int ret;
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
+
phy_lock_mdio_bus(phydev);
ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask, set);
phy_unlock_mdio_bus(phydev);
@@ -671,6 +713,9 @@ int __phy_modify_mmd(struct phy_device *phydev, int
devad, u32 regnum,
{
int ret;
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask, set);
return ret < 0 ? ret : 0;
@@ -694,6 +739,9 @@ int phy_modify_mmd(struct phy_device *phydev, int
devad, u32 regnum,
{
int ret;
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
phy_lock_mdio_bus(phydev);
ret = __phy_modify_mmd(phydev, devad, regnum, mask, set);
phy_unlock_mdio_bus(phydev);
@@ -704,7 +752,11 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
static int __phy_read_page(struct phy_device *phydev)
{
- if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not
available, PHY driver not loaded?\n"))
+
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
+ if (WARN(!phydev->drv->read_page, "read_page callback not
available, PHY driver not loaded?\n"))
return -EOPNOTSUPP;
return phydev->drv->read_page(phydev);
@@ -712,12 +764,16 @@ static int __phy_read_page(struct phy_device *phydev)
static int __phy_write_page(struct phy_device *phydev, int page)
{
- if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not
available, PHY driver not loaded?\n"))
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
+ if (WARN(!phydev->drv->write_page, "write_page callback not
available, PHY driver not loaded?\n"))
return -EOPNOTSUPP;
return phydev->drv->write_page(phydev, page);
}
+
/**
* phy_save_page() - take the bus lock and save the current page
* @phydev: a pointer to a &struct phy_device
@@ -728,7 +784,11 @@ static int __phy_write_page(struct phy_device
*phydev, int page)
*/
int phy_save_page(struct phy_device *phydev)
{
- phy_lock_mdio_bus(phydev);
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
+
+ phy_lock_mdio_bus(phydev);
return __phy_read_page(phydev);
}
EXPORT_SYMBOL_GPL(phy_save_page);
@@ -748,7 +808,10 @@ int phy_select_page(struct phy_device *phydev, int
page)
{
int ret, oldpage;
- oldpage = ret = phy_save_page(phydev);
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
+ oldpage = ret = phy_save_page(phydev);
if (ret < 0)
return ret;
@@ -782,6 +845,9 @@ int phy_restore_page(struct phy_device *phydev, int
oldpage, int ret)
{
int r;
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
if (oldpage >= 0) {
r = __phy_write_page(phydev, oldpage);
@@ -812,6 +878,9 @@ EXPORT_SYMBOL_GPL(phy_restore_page);
int phy_read_paged(struct phy_device *phydev, int page, u32 regnum)
{
int ret = 0, oldpage;
+
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
oldpage = phy_select_page(phydev, page);
if (oldpage >= 0)
@@ -834,6 +903,10 @@ int phy_write_paged(struct phy_device *phydev, int
page, u32 regnum, u16 val)
{
int ret = 0, oldpage;
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
+
oldpage = phy_select_page(phydev, page);
if (oldpage >= 0)
ret = __phy_write(phydev, regnum, val);
@@ -856,6 +929,9 @@ int phy_modify_paged_changed(struct phy_device
*phydev, int page, u32 regnum,
u16 mask, u16 set)
{
int ret = 0, oldpage;
+
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
oldpage = phy_select_page(phydev, page);
if (oldpage >= 0)
@@ -878,7 +954,12 @@ EXPORT_SYMBOL(phy_modify_paged_changed);
int phy_modify_paged(struct phy_device *phydev, int page, u32 regnum,
u16 mask, u16 set)
{
- int ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
+ int ret = -1;
+
+ /* If not attached, do nothing. */
+ PHY_NOT_ATTACHED_CHECK;
+
+ ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
return ret < 0 ? ret : 0;
}
--
2.26.2
>>> |
>>>
>>> |
>>> |
>>>
>>> |I've documented current state to Manjaro's forum:
>>> https://forum.manjaro.org/t/your-post-in-r8168-kernel-5-6-3-driver-broken/139869/3
>>> .. after i cleanup debugs away and do speedtests. Could the fix be
>>> something to considerate to upstream ?|
>>>
>>> |
>>> |
>>>
>>> |The fix I'm proposing is not the reload hack, but just kernel
>>> modifications.
>>> |
>>>
>>>
>>>>>>>>>>>>>>>>>>>> The problem with old method seems to be, that
>>>>>>>>>>>>>>>>>>>> device does not have had time to attach before the
>>>>>>>>>>>>>>>>>>>> PHY driver check.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The patch:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> diff --git
>>>>>>>>>>>>>>>>>>>> a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>>>>> index bf5bf05970a2..acd122a88d4a 100644
>>>>>>>>>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>>>>>>>>> @@ -5172,11 +5172,11 @@ static int
>>>>>>>>>>>>>>>>>>>> r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>>>>>>>>>> - } else if (!tp->phydev->drv) {
>>>>>>>>>>>>>>>>>>>> + } else if (tp->mac_version ==
>>>>>>>>>>>>>>>>>>>> RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>>>>>>>>>> /* Most chip versions fail
>>>>>>>>>>>>>>>>>>>> with the genphy driver.
>>>>>>>>>>>>>>>>>>>> * Therefore ensure that the
>>>>>>>>>>>>>>>>>>>> dedicated PHY driver is loaded.
>>>>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe
>>>>>>>>>>>>>>>>>>>> it needs to be added to initramfs?\n");
>>>>>>>>>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>>>>>>>>> return -EUNATCH;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>> diff --git a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>>>>> b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>>>>> index 66b8c61ca74c..aba2b304b821 100644
>>>>>>>>>>>>>>>>>>>> --- a/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>>>>> +++ b/drivers/net/phy/phy-core.c
>>>>>>>>>>>>>>>>>>>> @@ -704,6 +704,10 @@
>>>>>>>>>>>>>>>>>>>> EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>>>>>>>>>>>>>>>>> static int __phy_read_page(struct
>>>>>>>>>>>>>>>>>>>> phy_device *phydev)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> if (WARN_ONCE(!phydev->drv->read_page,
>>>>>>>>>>>>>>>>>>>> "read_page callback not available, PHY driver not
>>>>>>>>>>>>>>>>>>>> loaded?\n"))
>>>>>>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>>>>> @@ -712,12 +716,17 @@ static int
>>>>>>>>>>>>>>>>>>>> __phy_read_page(struct phy_device *phydev)
>>>>>>>>>>>>>>>>>>>> static int __phy_write_page(struct
>>>>>>>>>>>>>>>>>>>> phy_device *phydev, int page)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> + /* If not attached, do nothing (no warning) */
>>>>>>>>>>>>>>>>>>>> + if (!phydev->attached_dev)
>>>>>>>>>>>>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>> (WARN_ONCE(!phydev->drv->write_page, "write_page
>>>>>>>>>>>>>>>>>>>> callback not available, PHY driver not loaded?\n"))
>>>>>>>>>>>>>>>>>>>> return -EOPNOTSUPP;
>>>>>>>>>>>>>>>>>>>> return
>>>>>>>>>>>>>>>>>>>> phydev->drv->write_page(phydev, page);
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> /**
>>>>>>>>>>>>>>>>>>>> * phy_save_page() - take the bus lock and
>>>>>>>>>>>>>>>>>>>> save the current page
>>>>>>>>>>>>>>>>>>>> * @phydev: a pointer to a &struct phy_device
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit
>>>>>>>>>>>>>>>>>>>> <hkallweit1@gmail.com
>>>>>>>>>>>>>>>>>>>> <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi, There seems to he Something odd
>>>>>>>>>>>>>>>>>>>> problem, maybe timing related. Stripped version not
>>>>>>>>>>>>>>>>>>>> workingas expected. I get back to you, when i have
>>>>>>>>>>>>>>>>>>>> it working.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> There's no point in working on your patch.
>>>>>>>>>>>>>>>>>>>> W/o proper justification it
>>>>>>>>>>>>>>>>>>>> isn't acceptable anyway. And so far we
>>>>>>>>>>>>>>>>>>>> still don't know which problem
>>>>>>>>>>>>>>>>>>>> you actually have.
>>>>>>>>>>>>>>>>>>>> FIRST please provide the requested logs
>>>>>>>>>>>>>>>>>>>> and explain the actual problem
>>>>>>>>>>>>>>>>>>>> (incl. the commit that caused the
>>>>>>>>>>>>>>>>>>>> regression).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku
>>>>>>>>>>>>>>>>>>>> <ljakku77@gmail.com <mailto:ljakku77@gmail.com>>
>>>>>>>>>>>>>>>>>>>> kirjoitti: Hi, Fair enough, i'll strip them. -lja
>>>>>>>>>>>>>>>>>>>> On 2020-04-13 14:34, Leon Romanovsky wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Mon, Apr 13, 2020 at 02:02:01PM
>>>>>>>>>>>>>>>>>>>> +0300, Lauri Jakku wrote: Hi, Comments inline. On
>>>>>>>>>>>>>>>>>>>> 2020-04-13 13:58, Leon Romanovsky wrote: On Mon,
>>>>>>>>>>>>>>>>>>>> Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku
>>>>>>>>>>>>>>>>>>>> wrote: From
>>>>>>>>>>>>>>>>>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17
>>>>>>>>>>>>>>>>>>>> 00:00:00 2001 From: Lauri Jakku <lja@iki.fi> Date:
>>>>>>>>>>>>>>>>>>>> Mon, 13 Apr 2020 13:18:35 +0300 Subject: [PATCH]
>>>>>>>>>>>>>>>>>>>> NET: r8168/r8169 identifying fix The driver
>>>>>>>>>>>>>>>>>>>> installation determination made properly by
>>>>>>>>>>>>>>>>>>>> checking PHY vs DRIVER id's. ---
>>>>>>>>>>>>>>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70
>>>>>>>>>>>>>>>>>>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c
>>>>>>>>>>>>>>>>>>>> | 11 +++- 2 files changed, 72 insertions(+), 9
>>>>>>>>>>>>>>>>>>>> deletions(-) I would say that most of the code is
>>>>>>>>>>>>>>>>>>>> debug prints. I tought that they are helpful to
>>>>>>>>>>>>>>>>>>>> keep, they are using the debug calls, so they are
>>>>>>>>>>>>>>>>>>>> not visible if user does not like those. You are
>>>>>>>>>>>>>>>>>>>> missing the point of who are your users. Users want
>>>>>>>>>>>>>>>>>>>> to have working device and the code. They don't
>>>>>>>>>>>>>>>>>>>> need or like to debug their kernel. Thanks
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>
^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-05-03 1:34 ` Lauri Jakku
@ 2020-05-03 2:28 ` Lauri Jakku
2020-05-03 8:33 ` Heiner Kallweit
0 siblings, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-05-03 2:28 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 3.5.2020 4.34, Lauri Jakku wrote:
> Hi,
>
>
> On 3.5.2020 3.11, Lauri Jakku wrote:
>>
>> On 3.5.2020 2.15, Heiner Kallweit wrote:
>>> On 03.05.2020 00:42, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>>
>>>>
>>>> On 2.5.2020 20.56, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>> On 1.5.2020 22.12, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> On 19.4.2020 19.00, Heiner Kallweit wrote:
>>>>>>> On 19.04.2020 18:49, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without
>>>>>>>>>>>>>>>>>>>>> modifications --> network does not work
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified
>>>>>>>>>>>>>>>>>>>>> kernel (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched
>>>>>>>>>>>>>>>>>>>>> + r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're
>>>>>>>>>>>>>>>>>>>> presumable affected by a known BIOS bug.
>>>>>>>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at
>>>>>>>>>>>>>>>>>>>> bugzilla.kernel.org.
>>>>>>>>>>>>>>>>>>>> In the first referenced tickets it's about the same
>>>>>>>>>>>>>>>>>>>> mainboard (with earlier BIOS version).
>>>>>>>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the
>>>>>>>>>>>>>>>>>>>> network chip / PHY correctly, it reports
>>>>>>>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY
>>>>>>>>>>>>>>>>>>>> driver being found.
>>>>>>>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your
>>>>>>>>>>>>>>>>>>>> problem should be gone.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now
>>>>>>>>>>>>>>>>>> testing some mutex guard for phy state and try to use
>>>>>>>>>>>>>>>>>> it as indicator
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> that attach has been done. One thing i've noticed is
>>>>>>>>>>>>>>>>>> that driver needs to be reloaded to allow traffic
>>>>>>>>>>>>>>>>>> (ie. ping works etc.)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> All that shouldn't be needed. Just check with which
>>>>>>>>>>>>>>>>> PHY ID the PHY comes up.
>>>>>>>>>>>>>>>>> And what do you mean with "it seems"? Is the option
>>>>>>>>>>>>>>>>> enabled or not?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I do have ROM's enabled, and it does not help with my
>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>> Your BIOS is a beta version, downgrading to F7 may help.
>>>>>>>>>>>>>> Then you have the same
>>>>>>>>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>> 0000:03:00.0: MAC version: 23
>>>>>>>>>>>>>
>>>>>>>>>>>>> ....
>>>>>>>>>>>>>
>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>
>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>> 0000:02:00.0: MAC version: 23
>>>>>>>>>>>>>
>>>>>>>>>>>>> .. after module unload & load cycle:
>>>>>>>>>>>>>
>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>> 0000:02:00.0: MAC version: 23
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> it seem to be the case that the phy_id chances onetime,
>>>>>>>>>>>>> then stays the same. I'll do few shutdowns and see
>>>>>>>>>>>>>
>>>>>>>>>>>>> is there a pattern at all .. next i'm going to try how it
>>>>>>>>>>>>> behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The BIOS downgrade: I'd like to solve this without
>>>>>>>>>>>>> downgrading BIOS. If I can't, then I'll do systemd-service
>>>>>>>>>>>>> that
>>>>>>>>>>>>>
>>>>>>>>>>>>> reloads r8169 driver at boot, cause then network is just
>>>>>>>>>>>>> fine.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> What i've gathered samples now, there is three values for
>>>>>>>>>>>> PHY ID:
>>>>>>>>>>>>
>>>>>>>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl
>>>>>>>>>>>> |grep "PHY ver"
>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: PHY version: 0xc2077002
>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>
>>>>>>>>>>>> I dont know are those hard coded or what, and are they
>>>>>>>>>>>> device specific how much.
>>>>>>>>>>>>
>>>>>>>>>>>> i haven't coldbooted things up, that may be that something
>>>>>>>>>>>> to check do they vary how per coldboot.
>>>>>>>>>>>>
>>>>>>>>>>>>>>> I check the ID, and revert all other changes, and check
>>>>>>>>>>>>>>> how it is working after adding the PHY id to list.
>>>>>>>>>>>>>>>
>>>>>>>>>>> What i've now learned: the patch + script + journald
>>>>>>>>>>> services -> Results working network, but it is still a
>>>>>>>>>>> workaround.
>>>>>>>>>>>
>>>>>>>>>> Following patch trusts the MAC version, another thing witch
>>>>>>>>>> could help is to derive method to do 2dn pass of the probeing:
>>>>>>>>>>
>>>>>>>>>> if specific MAC version is found.
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>> index acd122a88d4a..62b37a1abc24 100644
>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct
>>>>>>>>>> rtl8169_private *tp)
>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>> return -ENODEV;
>>>>>>>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>> - /* Most chip versions fail with the genphy
>>>>>>>>>> driver.
>>>>>>>>>> - * Therefore ensure that the dedicated PHY
>>>>>>>>>> driver is loaded.
>>>>>>>>>> - */
>>>>>>>>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>> - mdiobus_unregister(new_bus);
>>>>>>>>>> - return -EUNATCH;
>>>>>>>>>> + } else {
>>>>>>>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n",
>>>>>>>>>> tp->phydev->phy_id);
>>>>>>>>>> + dev_info(&pdev->dev, "MAC version: %d\n",
>>>>>>>>>> tp->mac_version);
>>>>>>>>>> +
>>>>>>>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>> + /* Most chip versions fail with the
>>>>>>>>>> genphy driver.
>>>>>>>>>> + * Therefore ensure that the
>>>>>>>>>> dedicated PHY driver is loaded.
>>>>>>>>>> + */
>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n",
>>>>>>>>>> tp->phydev->phy_id);
>>>>>>>>>> + mdiobus_unregister(new_bus);
>>>>>>>>>> + return -EUNATCH;
>>>>>>>>>> + }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>>>>>
>>>>>>>>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's
>>>>>>>>> updated.. and now up'n'running. There is one (WARN_ONCE)
>>>>>>>>> stack trace coming from driver, i think i tinker with it next,
>>>>>>>>> with above patch the network devices shows up and they can be
>>>>>>>>> configured.
>>>>>>>>>
>>>>>>>> I tought to ask first, before going to make new probe_type for
>>>>>>>> errorneus hw (propetype + retry counter) to do re-probe if
>>>>>>>> requested, N times. Or should the r8169_main.c return deferred
>>>>>>>> probe on error on some MAC enums ? Which approach is
>>>>>>>> design-wise sound ?
>>>>>>>>
>>>>>>>> I just tought that the DEFERRED probe may just do the trick i'm
>>>>>>>> looking ways to implement the re-probeing... hmm. I try the
>>>>>>>> deferred thing and check would that help.
>>>>>>>>
>>>>>>> Playing with options to work around the issue is of course a
>>>>>>> great way to
>>>>>>> learn about the kernel. However it's questionable whether a
>>>>>>> workaround in
>>>>>>> the driver is acceptable for dealing with the broken BIOS of
>>>>>>> exactly one
>>>>>>>> 10 yrs old board (for which even a userspace workaround exists).
>>>>>> problem recognized: libphy-module get's unloaded for some reason
>>>>>> before r8169 driver loads -> missing lowlevel functionality ->
>>>>>> not working driver. This only occurs at 1st load of module..
>>>>>> seeking solution.
>>>>>>
>>>>>>
>>>>>> There is [last unloaded: libphy] entries in log BEFORE r8169 is
>>>>>> probed first time.
>>>>>>
>>>>>>
>>>>>> Any clue what is responsible for unloading to occur ?
>>>>>>
>>>>>>
>>>>> Right now I'm debugging what is the reason, behind that the module
>>>>> starts to work properly only when
>>>>>
>>>>> unload & reload cycle is done.
>>>>>
>>>>>
>>>>> The libphy is listed as loaded, but the check for low level
>>>>> read/write function is not set -> r8169 modules rlt_open() fails.
>>>>>
>>>>> See here:
>>>>>
>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: ------------[ cut
>>>>> here ]------------
>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: read_page callback
>>>>> not available, PHY driver not loaded?
>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: WARNING: CPU: 3 PID:
>>>>> 787 at drivers/net/phy/phy-core.c:750 phy_save_page+0xb1/0xe3 [libph
>>>>> y]
>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Modules linked in:
>>>>> cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm
>>>>> btintel b
>>>>> luetooth ecdh_generic rfkill ecc uvcvideo videobuf2_vmalloc
>>>>> videobuf2_memops snd_usb_audio videobuf2_v4l2 videobuf2_common
>>>>> snd_usbmidi_
>>>>> lib videodev snd_rawmidi snd_seq_device mc input_leds joydev
>>>>> mousedev squashfs loop amdgpu snd_hda_codec_realtek gpu_sched
>>>>> i2c_algo_bit
>>>>> ttm snd_hda_codec_generic drm_kms_helper edac_mce_amd
>>>>> ledtrig_audio cec rc_core kvm_amd drm ccp snd_hda_codec_hdmi
>>>>> agpgart rng_core kv
>>>>> m snd_hda_intel syscopyarea sysfillrect ppdev sysimgblt
>>>>> snd_intel_dspcfg fb_sys_fops snd_hda_codec snd_hda_core snd_hwdep
>>>>> irqbypass wmi
>>>>> _bmof snd_pcm snd_timer snd evdev pcspkr soundcore parport_pc
>>>>> parport sp5100_tco mac_hid i2c_piix4 k10temp acpi_cpufreq uinput
>>>>> crypto_u
>>>>> ser ip_tables x_tables hid_generic usbhid hid ohci_pci virtio_net
>>>>> net_failover failover firewire_ohci firewire_core crc_itu_t pata_atii
>>>>> xp ehci_pci ehci_hcd sr_mod cdrom ohci_hcd ata_generic pata_acpi
>>>>> pata_jmicron wmi floppy
>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: r8169 realtek libphy
>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: CPU: 3 PID: 787
>>>>> Comm: NetworkManager Not tainted 5.7.0-1-raw #12
>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Hardware name:
>>>>> Gigabyte Technology Co., Ltd. GA-MA790FXT-UD5P/GA-MA790FXT-UD5P,
>>>>> BIOS F8l 07/15/2010
>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RIP:
>>>>> 0010:phy_save_page+0xb1/0xe3 [libphy]
>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Code: c8 82 11 c0 e8
>>>>> 06 28 ff cc 85 db 74 47 48 8b 85 48 03 00 00 48 83 b8 68 01 00 00
>>>>> 00 75 10 48 c7 c7 e8 82 11 c0 e8 a9 dd f7 cc <0f> 0b eb 26 48 c7
>>>>> c7 52 78 11 c0 e8 99 dd f7 cc 0f 0b 48 8b 85 48
>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RSP:
>>>>> 0018:ffff962c408ef370 EFLAGS: 00010282
>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RAX:
>>>>> 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RDX:
>>>>> 0000000000000001 RSI: 0000000000000092 RDI: 00000000ffffffff
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: RBP:
>>>>> ffff8b1af3eb8800 R08: 00000000000004b3 R09: 0000000000000004
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R10:
>>>>> 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffa1
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R13:
>>>>> 0000000000000002 R14: 0000000000000002 R15: ffff8b1af3eb8800
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: FS:
>>>>> 00007f07be5d4d80(0000) GS:ffff8b1af7cc0000(0000)
>>>>> knlGS:0000000000000000
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CS: 0010 DS: 0000
>>>>> ES: 0000 CR0: 0000000080050033
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CR2:
>>>>> 000055b83aecb008 CR3: 00000002246b0000 CR4: 00000000000006e0
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: Call Trace:
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>> phy_select_page+0x53/0x7a [libphy]
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>> phy_write_paged+0x5c/0xa0 [libphy]
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>> rtl8168d_1_hw_phy_config+0x9d/0x210 [r8169]
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>> rtl8169_init_phy+0x19/0x110 [r8169]
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl_open+0x354/0x4d0
>>>>> [r8169]
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_open+0xe0/0x170
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>> __dev_change_flags+0x188/0x1e0
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>> dev_change_flags+0x21/0x60
>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: do_setlink+0x78a/0xfd0
>>>>>
>>>>>
>>>>> Something does not setup/register properly at first the way it
>>>>> should.
>>>>>
>>>>>
>>>> I think i solved it: realtek (the phy driver) was missing device
>>>> entry for the PHY ID reported by the NIC to match -> read_page and
>>>> write_page function pointers should now be set. The generic PHY
>>>> does not fill
>>>>
>>>> the driver's functionality to read or write pages. It happens to be
>>>> so that the drivers for |RTL8211B Gigabit Ethernet seems to work
>>>> just fine for my NIC's.
>>> The analysis is wrong. The incorrect PHY ID is not root cause of the
>>> problem, it's caused by a BIOS bug. It's not a valid PHY ID. If you
>>> want
>>> to do something, then you could try to inject a PHY soft reset before
>>> the MII bus is registered. This should be board-specific, e.g. using
>>> dmi_check_system().
>>
>> Ok, i'll try that approach, thanks for the tip. Hmm, I'll do similar
>> function mapping what the HW init/config function does determine
>>
>> function to use.
>>
>>
>> I'll get back to you when I got something new developed.
>>
> Oujeah, now it works OK.. the soft reset was all it needed.
>
>
> Here's the patch:
>
> From 06c5deacf3ca9f9258431756a41ff0ba1792f1f7 Mon Sep 17 00:00:00 2001
> From: Lauri Jakku <lja@iki.fi>
> Date: Thu, 16 Apr 2020 00:38:51 +0300
> Subject: [PATCH] NET: r8169 driver identifying improvement.
>
> Trust device MAC enum + r8169d NIC soft reset
> before configuration.
>
> This commit adds enumeration check and allows
> driver to be slow to attach.
>
> Signed-off-by: Lauri Jakku <lja@iki.fi>
> ---
> drivers/net/ethernet/realtek/r8169_main.c | 24 +++--
> .../net/ethernet/realtek/r8169_phy_config.c | 80 ++++++++++++++++
> drivers/net/phy/phy-core.c | 91 ++++++++++++++++++-
> 3 files changed, 182 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
> b/drivers/net/ethernet/realtek/r8169_main.c
> index bf5bf05970a2..a85764f6e448 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -640,7 +640,6 @@ MODULE_AUTHOR("Realtek and the Linux r8169 crew
> <netdev@vger.kernel.org>");
> MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
> module_param_named(debug, debug.msg_enable, int, 0);
> MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
> -MODULE_SOFTDEP("pre: realtek");
> MODULE_LICENSE("GPL");
> MODULE_FIRMWARE(FIRMWARE_8168D_1);
> MODULE_FIRMWARE(FIRMWARE_8168D_2);
> @@ -5172,13 +5171,18 @@ static int r8169_mdio_register(struct
> rtl8169_private *tp)
> if (!tp->phydev) {
> mdiobus_unregister(new_bus);
> return -ENODEV;
> - } else if (!tp->phydev->drv) {
> - /* Most chip versions fail with the genphy driver.
> - * Therefore ensure that the dedicated PHY driver is loaded.
> - */
> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to
> be added to initramfs?\n");
> - mdiobus_unregister(new_bus);
> - return -EUNATCH;
> + } else {
> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
> +
> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
> + /* Most chip versions fail with the genphy driver.
> + * Therefore ensure that the dedicated PHY driver is loaded.
> + */
> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n");
> + mdiobus_unregister(new_bus);
> + return -EUNATCH;
> + }
> }
>
> /* PHY will be woken up in rtl_open() */
> @@ -5513,6 +5517,9 @@ static int rtl_init_one(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> rtl_chip_infos[chipset].name, dev->dev_addr, xid,
> pci_irq_vector(pdev, 0));
>
> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
> +
> if (jumbo_max)
> netif_info(tp, probe, dev,
> "jumbo features [frames: %d bytes, tx checksumming:
> %s]\n",
> @@ -5532,6 +5539,7 @@ static int rtl_init_one(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> return rc;
> }
>
> +
> static struct pci_driver rtl8169_pci_driver = {
> .name = MODULENAME,
> .id_table = rtl8169_pci_tbl,
> diff --git a/drivers/net/ethernet/realtek/r8169_phy_config.c
> b/drivers/net/ethernet/realtek/r8169_phy_config.c
> index b73f7d023e99..73d604c7a8a8 100644
> --- a/drivers/net/ethernet/realtek/r8169_phy_config.c
> +++ b/drivers/net/ethernet/realtek/r8169_phy_config.c
> @@ -1243,6 +1243,84 @@ static void rtl8125_2_hw_phy_config(struct
> rtl8169_private *tp,
> rtl8125_config_eee_phy(phydev);
> }
>
> +
> +static void rtl8168d_hw_phy_pre_config_actions(struct rtl8169_private
> *tp,
> + struct phy_device *phydev)
> +{
> + /* Reset the PHY before configuration. There is BIOS bug that gives
> + * random PHY ID when device is not soft resetted first. --lja
> + */
> + genphy_soft_reset(phydev);
> +}
> +
> +
> +
> +void r8169_hw_phy_pre_config_actions(struct rtl8169_private *tp,
> struct phy_device *phydev,
> + enum mac_version ver)
> +{
> + static const rtl_phy_cfg_fct phy_pre_config_actions[] = {
> + /* PCI devices. */
> + [RTL_GIGA_MAC_VER_02] = NULL,
> + [RTL_GIGA_MAC_VER_03] = NULL,
> + [RTL_GIGA_MAC_VER_04] = NULL,
> + [RTL_GIGA_MAC_VER_05] = NULL,
> + [RTL_GIGA_MAC_VER_06] = NULL,
> + /* PCI-E devices. */
> + [RTL_GIGA_MAC_VER_07] = NULL,
> + [RTL_GIGA_MAC_VER_08] = NULL,
> + [RTL_GIGA_MAC_VER_09] = NULL,
> + [RTL_GIGA_MAC_VER_10] = NULL,
> + [RTL_GIGA_MAC_VER_11] = NULL,
> + [RTL_GIGA_MAC_VER_12] = NULL,
> + [RTL_GIGA_MAC_VER_13] = NULL,
> + [RTL_GIGA_MAC_VER_14] = NULL,
> + [RTL_GIGA_MAC_VER_15] = NULL,
> + [RTL_GIGA_MAC_VER_16] = NULL,
> + [RTL_GIGA_MAC_VER_17] = NULL,
> + [RTL_GIGA_MAC_VER_18] = NULL,
> + [RTL_GIGA_MAC_VER_19] = NULL,
> + [RTL_GIGA_MAC_VER_20] = NULL,
> + [RTL_GIGA_MAC_VER_21] = NULL,
> + [RTL_GIGA_MAC_VER_22] = NULL,
> + [RTL_GIGA_MAC_VER_23] = NULL,
> + [RTL_GIGA_MAC_VER_24] = NULL,
> + [RTL_GIGA_MAC_VER_25] = rtl8168d_hw_phy_pre_config_actions,
> + [RTL_GIGA_MAC_VER_26] = rtl8168d_hw_phy_pre_config_actions,
> + [RTL_GIGA_MAC_VER_27] = rtl8168d_hw_phy_pre_config_actions,
> + [RTL_GIGA_MAC_VER_28] = rtl8168d_hw_phy_pre_config_actions,
> + [RTL_GIGA_MAC_VER_29] = NULL,
> + [RTL_GIGA_MAC_VER_30] = NULL,
> + [RTL_GIGA_MAC_VER_31] = NULL,
> + [RTL_GIGA_MAC_VER_32] = NULL,
> + [RTL_GIGA_MAC_VER_33] = NULL,
> + [RTL_GIGA_MAC_VER_34] = NULL,
> + [RTL_GIGA_MAC_VER_35] = NULL,
> + [RTL_GIGA_MAC_VER_36] = NULL,
> + [RTL_GIGA_MAC_VER_37] = NULL,
> + [RTL_GIGA_MAC_VER_38] = NULL,
> + [RTL_GIGA_MAC_VER_39] = NULL,
> + [RTL_GIGA_MAC_VER_40] = NULL,
> + [RTL_GIGA_MAC_VER_41] = NULL,
> + [RTL_GIGA_MAC_VER_42] = NULL,
> + [RTL_GIGA_MAC_VER_43] = NULL,
> + [RTL_GIGA_MAC_VER_44] = NULL,
> + [RTL_GIGA_MAC_VER_45] = NULL,
> + [RTL_GIGA_MAC_VER_46] = NULL,
> + [RTL_GIGA_MAC_VER_47] = NULL,
> + [RTL_GIGA_MAC_VER_48] = NULL,
> + [RTL_GIGA_MAC_VER_49] = NULL,
> + [RTL_GIGA_MAC_VER_50] = NULL,
> + [RTL_GIGA_MAC_VER_51] = NULL,
> + [RTL_GIGA_MAC_VER_52] = NULL,
> + [RTL_GIGA_MAC_VER_60] = NULL,
> + [RTL_GIGA_MAC_VER_61] = NULL,
> + };
> +
> + if (phy_pre_config_actions[ver])
> + phy_pre_config_actions[ver](tp, phydev);
> +}
> +
> +
> void r8169_hw_phy_config(struct rtl8169_private *tp, struct
> phy_device *phydev,
> enum mac_version ver)
> {
> @@ -1303,6 +1381,8 @@ void r8169_hw_phy_config(struct rtl8169_private
> *tp, struct phy_device *phydev,
> [RTL_GIGA_MAC_VER_60] = rtl8125_1_hw_phy_config,
> [RTL_GIGA_MAC_VER_61] = rtl8125_2_hw_phy_config,
> };
> +
> + r8169_hw_phy_pre_config_actions(tp, phydev);
>
> if (phy_configs[ver])
> phy_configs[ver](tp, phydev);
> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
> index 66b8c61ca74c..b170185a1ed1 100644
> --- a/drivers/net/phy/phy-core.c
> +++ b/drivers/net/phy/phy-core.c
> @@ -151,6 +151,25 @@ static const struct phy_setting settings[] = {
> };
> #undef PHY_SETTING
>
> +#ifdef DEBUG
> +#define R8169_ATTACHED_PRINTK \
> + printk("Phy is attached check %s @ %d: %d\n", \
> + __FUNC__, __LINE__, is_attached_check);
> +
> +#else
> +#define R8169_ATTACHED_PRINTK
> +#endif
> +
> +#define PHY_NOT_ATTACHED_CHECK \
> + { \
> + void *attached_dev_ptr = (phydev) ? phydev->attached_dev :
> NULL; \
> + int is_attached_check = (attached_dev_ptr != NULL) && \
> + ((phydev) && (phydev->state >=
> PHY_READY)); \
> + R8169_ATTACHED_PRINTK \
> + if (! is_attached_check ) return -EOPNOTSUPP; \
> + };
> +
> +
> /**
> * phy_lookup_setting - lookup a PHY setting
> * @speed: speed to match
> @@ -457,6 +476,9 @@ int phy_read_mmd(struct phy_device *phydev, int
> devad, u32 regnum)
> {
> int ret;
>
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> phy_lock_mdio_bus(phydev);
> ret = __phy_read_mmd(phydev, devad, regnum);
> phy_unlock_mdio_bus(phydev);
> @@ -479,6 +501,9 @@ int __phy_write_mmd(struct phy_device *phydev, int
> devad, u32 regnum, u16 val)
> {
> int ret;
>
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> if (regnum > (u16)~0 || devad > 32)
> return -EINVAL;
>
> @@ -518,6 +543,9 @@ int phy_write_mmd(struct phy_device *phydev, int
> devad, u32 regnum, u16 val)
> {
> int ret;
>
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> phy_lock_mdio_bus(phydev);
> ret = __phy_write_mmd(phydev, devad, regnum, val);
> phy_unlock_mdio_bus(phydev);
> @@ -543,6 +571,10 @@ int phy_modify_changed(struct phy_device *phydev,
> u32 regnum, u16 mask, u16 set)
> {
> int ret;
>
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> +
> phy_lock_mdio_bus(phydev);
> ret = __phy_modify_changed(phydev, regnum, mask, set);
> phy_unlock_mdio_bus(phydev);
> @@ -587,6 +619,9 @@ int phy_modify(struct phy_device *phydev, u32
> regnum, u16 mask, u16 set)
> {
> int ret;
>
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> phy_lock_mdio_bus(phydev);
> ret = __phy_modify(phydev, regnum, mask, set);
> phy_unlock_mdio_bus(phydev);
> @@ -613,6 +648,9 @@ int __phy_modify_mmd_changed(struct phy_device
> *phydev, int devad, u32 regnum,
> {
> int new, ret;
>
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> ret = __phy_read_mmd(phydev, devad, regnum);
> if (ret < 0)
> return ret;
> @@ -646,6 +684,10 @@ int phy_modify_mmd_changed(struct phy_device
> *phydev, int devad, u32 regnum,
> {
> int ret;
>
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> +
> phy_lock_mdio_bus(phydev);
> ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask, set);
> phy_unlock_mdio_bus(phydev);
> @@ -671,6 +713,9 @@ int __phy_modify_mmd(struct phy_device *phydev,
> int devad, u32 regnum,
> {
> int ret;
>
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask, set);
>
> return ret < 0 ? ret : 0;
> @@ -694,6 +739,9 @@ int phy_modify_mmd(struct phy_device *phydev, int
> devad, u32 regnum,
> {
> int ret;
>
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> phy_lock_mdio_bus(phydev);
> ret = __phy_modify_mmd(phydev, devad, regnum, mask, set);
> phy_unlock_mdio_bus(phydev);
> @@ -704,7 +752,11 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>
> static int __phy_read_page(struct phy_device *phydev)
> {
> - if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not
> available, PHY driver not loaded?\n"))
> +
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> + if (WARN(!phydev->drv->read_page, "read_page callback not
> available, PHY driver not loaded?\n"))
> return -EOPNOTSUPP;
>
> return phydev->drv->read_page(phydev);
> @@ -712,12 +764,16 @@ static int __phy_read_page(struct phy_device
> *phydev)
>
> static int __phy_write_page(struct phy_device *phydev, int page)
> {
> - if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not
> available, PHY driver not loaded?\n"))
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> + if (WARN(!phydev->drv->write_page, "write_page callback not
> available, PHY driver not loaded?\n"))
> return -EOPNOTSUPP;
>
> return phydev->drv->write_page(phydev, page);
> }
>
> +
> /**
> * phy_save_page() - take the bus lock and save the current page
> * @phydev: a pointer to a &struct phy_device
> @@ -728,7 +784,11 @@ static int __phy_write_page(struct phy_device
> *phydev, int page)
> */
> int phy_save_page(struct phy_device *phydev)
> {
> - phy_lock_mdio_bus(phydev);
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> +
> + phy_lock_mdio_bus(phydev);
> return __phy_read_page(phydev);
> }
> EXPORT_SYMBOL_GPL(phy_save_page);
> @@ -748,7 +808,10 @@ int phy_select_page(struct phy_device *phydev,
> int page)
> {
> int ret, oldpage;
>
> - oldpage = ret = phy_save_page(phydev);
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> + oldpage = ret = phy_save_page(phydev);
> if (ret < 0)
> return ret;
>
> @@ -782,6 +845,9 @@ int phy_restore_page(struct phy_device *phydev,
> int oldpage, int ret)
> {
> int r;
>
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> if (oldpage >= 0) {
> r = __phy_write_page(phydev, oldpage);
>
> @@ -812,6 +878,9 @@ EXPORT_SYMBOL_GPL(phy_restore_page);
> int phy_read_paged(struct phy_device *phydev, int page, u32 regnum)
> {
> int ret = 0, oldpage;
> +
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
>
> oldpage = phy_select_page(phydev, page);
> if (oldpage >= 0)
> @@ -834,6 +903,10 @@ int phy_write_paged(struct phy_device *phydev,
> int page, u32 regnum, u16 val)
> {
> int ret = 0, oldpage;
>
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> +
> oldpage = phy_select_page(phydev, page);
> if (oldpage >= 0)
> ret = __phy_write(phydev, regnum, val);
> @@ -856,6 +929,9 @@ int phy_modify_paged_changed(struct phy_device
> *phydev, int page, u32 regnum,
> u16 mask, u16 set)
> {
> int ret = 0, oldpage;
> +
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
>
> oldpage = phy_select_page(phydev, page);
> if (oldpage >= 0)
> @@ -878,7 +954,12 @@ EXPORT_SYMBOL(phy_modify_paged_changed);
> int phy_modify_paged(struct phy_device *phydev, int page, u32 regnum,
> u16 mask, u16 set)
> {
> - int ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
> + int ret = -1;
> +
> + /* If not attached, do nothing. */
> + PHY_NOT_ATTACHED_CHECK;
> +
> + ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
>
> return ret < 0 ? ret : 0;
> }
here is the polished patch:
From 6dd6f2813c543dc728efb8dca796bbbe870bd031 Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Thu, 16 Apr 2020 00:38:51 +0300
Subject: [PATCH] NET: r8169 driver identifying improvement.
Trust device MAC enum + r8169d NIC soft reset
before configuration.
This commit adds enumeration check and allows
driver to be slow to attach.
Signed-off-by: Lauri Jakku <lja@iki.fi>
---
drivers/net/ethernet/realtek/r8169_main.c | 21 +++--
.../net/ethernet/realtek/r8169_phy_config.c | 80 +++++++++++++++++++
2 files changed, 93 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..6828e755a460 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -640,7 +640,6 @@ MODULE_AUTHOR("Realtek and the Linux r8169 crew
<netdev@vger.kernel.org>");
MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
module_param_named(debug, debug.msg_enable, int, 0);
MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
-MODULE_SOFTDEP("pre: realtek");
MODULE_LICENSE("GPL");
MODULE_FIRMWARE(FIRMWARE_8168D_1);
MODULE_FIRMWARE(FIRMWARE_8168D_2);
@@ -5172,13 +5171,18 @@ static int r8169_mdio_register(struct
rtl8169_private *tp)
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to
be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
+ dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
+
+ if (tp->mac_version == RTL_GIGA_MAC_NONE) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver is loaded.
+ */
+ dev_err(&pdev->dev, "Not known MAC/PHY version.\n");
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
@@ -5532,6 +5536,7 @@ static int rtl_init_one(struct pci_dev *pdev,
const struct pci_device_id *ent)
return rc;
}
+
static struct pci_driver rtl8169_pci_driver = {
.name = MODULENAME,
.id_table = rtl8169_pci_tbl,
diff --git a/drivers/net/ethernet/realtek/r8169_phy_config.c
b/drivers/net/ethernet/realtek/r8169_phy_config.c
index b73f7d023e99..f13f68b79a92 100644
--- a/drivers/net/ethernet/realtek/r8169_phy_config.c
+++ b/drivers/net/ethernet/realtek/r8169_phy_config.c
@@ -1243,6 +1243,84 @@ static void rtl8125_2_hw_phy_config(struct
rtl8169_private *tp,
rtl8125_config_eee_phy(phydev);
}
+
+static void rtl8168d_hw_phy_pre_config_actions(struct rtl8169_private *tp,
+ struct phy_device *phydev)
+{
+ /* Reset the PHY before configuration. There is BIOS bug that gives
+ * random PHY ID when device is not soft resetted first. --lja
+ */
+ genphy_soft_reset(phydev);
+}
+
+
+
+void r8169_hw_phy_pre_config_actions(struct rtl8169_private *tp, struct
phy_device *phydev,
+ enum mac_version ver)
+{
+ static const rtl_phy_cfg_fct phy_pre_config_actions[] = {
+ /* PCI devices. */
+ [RTL_GIGA_MAC_VER_02] = NULL,
+ [RTL_GIGA_MAC_VER_03] = NULL,
+ [RTL_GIGA_MAC_VER_04] = NULL,
+ [RTL_GIGA_MAC_VER_05] = NULL,
+ [RTL_GIGA_MAC_VER_06] = NULL,
+ /* PCI-E devices. */
+ [RTL_GIGA_MAC_VER_07] = NULL,
+ [RTL_GIGA_MAC_VER_08] = NULL,
+ [RTL_GIGA_MAC_VER_09] = NULL,
+ [RTL_GIGA_MAC_VER_10] = NULL,
+ [RTL_GIGA_MAC_VER_11] = NULL,
+ [RTL_GIGA_MAC_VER_12] = NULL,
+ [RTL_GIGA_MAC_VER_13] = NULL,
+ [RTL_GIGA_MAC_VER_14] = NULL,
+ [RTL_GIGA_MAC_VER_15] = NULL,
+ [RTL_GIGA_MAC_VER_16] = NULL,
+ [RTL_GIGA_MAC_VER_17] = NULL,
+ [RTL_GIGA_MAC_VER_18] = NULL,
+ [RTL_GIGA_MAC_VER_19] = NULL,
+ [RTL_GIGA_MAC_VER_20] = NULL,
+ [RTL_GIGA_MAC_VER_21] = NULL,
+ [RTL_GIGA_MAC_VER_22] = NULL,
+ [RTL_GIGA_MAC_VER_23] = NULL,
+ [RTL_GIGA_MAC_VER_24] = NULL,
+ [RTL_GIGA_MAC_VER_25] = rtl8168d_hw_phy_pre_config_actions,
+ [RTL_GIGA_MAC_VER_26] = rtl8168d_hw_phy_pre_config_actions,
+ [RTL_GIGA_MAC_VER_27] = rtl8168d_hw_phy_pre_config_actions,
+ [RTL_GIGA_MAC_VER_28] = rtl8168d_hw_phy_pre_config_actions,
+ [RTL_GIGA_MAC_VER_29] = NULL,
+ [RTL_GIGA_MAC_VER_30] = NULL,
+ [RTL_GIGA_MAC_VER_31] = NULL,
+ [RTL_GIGA_MAC_VER_32] = NULL,
+ [RTL_GIGA_MAC_VER_33] = NULL,
+ [RTL_GIGA_MAC_VER_34] = NULL,
+ [RTL_GIGA_MAC_VER_35] = NULL,
+ [RTL_GIGA_MAC_VER_36] = NULL,
+ [RTL_GIGA_MAC_VER_37] = NULL,
+ [RTL_GIGA_MAC_VER_38] = NULL,
+ [RTL_GIGA_MAC_VER_39] = NULL,
+ [RTL_GIGA_MAC_VER_40] = NULL,
+ [RTL_GIGA_MAC_VER_41] = NULL,
+ [RTL_GIGA_MAC_VER_42] = NULL,
+ [RTL_GIGA_MAC_VER_43] = NULL,
+ [RTL_GIGA_MAC_VER_44] = NULL,
+ [RTL_GIGA_MAC_VER_45] = NULL,
+ [RTL_GIGA_MAC_VER_46] = NULL,
+ [RTL_GIGA_MAC_VER_47] = NULL,
+ [RTL_GIGA_MAC_VER_48] = NULL,
+ [RTL_GIGA_MAC_VER_49] = NULL,
+ [RTL_GIGA_MAC_VER_50] = NULL,
+ [RTL_GIGA_MAC_VER_51] = NULL,
+ [RTL_GIGA_MAC_VER_52] = NULL,
+ [RTL_GIGA_MAC_VER_60] = NULL,
+ [RTL_GIGA_MAC_VER_61] = NULL,
+ };
+
+ if (phy_pre_config_actions[ver])
+ phy_pre_config_actions[ver](tp, phydev);
+}
+
+
void r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device
*phydev,
enum mac_version ver)
{
@@ -1304,6 +1382,8 @@ void r8169_hw_phy_config(struct rtl8169_private
*tp, struct phy_device *phydev,
[RTL_GIGA_MAC_VER_61] = rtl8125_2_hw_phy_config,
};
+ r8169_hw_phy_pre_config_actions(tp, phydev, ver);
+
if (phy_configs[ver])
phy_configs[ver](tp, phydev);
}
--
2.26.2
^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-05-03 2:28 ` Lauri Jakku
@ 2020-05-03 8:33 ` Heiner Kallweit
2020-05-03 13:54 ` Lauri Jakku
2020-05-11 13:09 ` Lauri Jakku
0 siblings, 2 replies; 57+ messages in thread
From: Heiner Kallweit @ 2020-05-03 8:33 UTC (permalink / raw)
To: Lauri Jakku; +Cc: Leon Romanovsky, netdev, nic_swsd
On 03.05.2020 04:28, Lauri Jakku wrote:
> Hi,
>
> On 3.5.2020 4.34, Lauri Jakku wrote:
>> Hi,
>>
>>
>> On 3.5.2020 3.11, Lauri Jakku wrote:
>>>
>>> On 3.5.2020 2.15, Heiner Kallweit wrote:
>>>> On 03.05.2020 00:42, Lauri Jakku wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> On 2.5.2020 20.56, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 1.5.2020 22.12, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> On 19.4.2020 19.00, Heiner Kallweit wrote:
>>>>>>>> On 19.04.2020 18:49, Lauri Jakku wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>>>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>>>>>>>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>>>>>>>>>>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>>>>>>>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>>>>>>>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>>>>>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
>>>>>>>>>>>>>>>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>>>>>>>>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then you have the same
>>>>>>>>>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: MAC version: 23
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> .. after module unload & load cycle:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> it seem to be the case that the phy_id chances onetime, then stays the same. I'll do few shutdowns and see
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> is there a pattern at all .. next i'm going to try how it behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The BIOS downgrade: I'd like to solve this without downgrading BIOS. If I can't, then I'll do systemd-service that
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> What i've gathered samples now, there is three values for PHY ID:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep "PHY ver"
>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>
>>>>>>>>>>>>> I dont know are those hard coded or what, and are they device specific how much.
>>>>>>>>>>>>>
>>>>>>>>>>>>> i haven't coldbooted things up, that may be that something to check do they vary how per coldboot.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I check the ID, and revert all other changes, and check how it is working after adding the PHY id to list.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>> What i've now learned: the patch + script + journald services -> Results working network, but it is still a workaround.
>>>>>>>>>>>>
>>>>>>>>>>> Following patch trusts the MAC version, another thing witch could help is to derive method to do 2dn pass of the probeing:
>>>>>>>>>>>
>>>>>>>>>>> if specific MAC version is found.
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>> index acd122a88d4a..62b37a1abc24 100644
>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>>>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>>>>> - */
>>>>>>>>>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>>> - mdiobus_unregister(new_bus);
>>>>>>>>>>> - return -EUNATCH;
>>>>>>>>>>> + } else {
>>>>>>>>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>>>>>>>>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>>>>>>>>>> +
>>>>>>>>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>> + /* Most chip versions fail with the genphy driver.
>>>>>>>>>>> + * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>>>>> + */
>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n", tp->phydev->phy_id);
>>>>>>>>>>> + mdiobus_unregister(new_bus);
>>>>>>>>>>> + return -EUNATCH;
>>>>>>>>>>> + }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>>>>>>
>>>>>>>>>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's updated.. and now up'n'running. There is one (WARN_ONCE) stack trace coming from driver, i think i tinker with it next, with above patch the network devices shows up and they can be configured.
>>>>>>>>>>
>>>>>>>>> I tought to ask first, before going to make new probe_type for errorneus hw (propetype + retry counter) to do re-probe if requested, N times. Or should the r8169_main.c return deferred probe on error on some MAC enums ? Which approach is design-wise sound ?
>>>>>>>>>
>>>>>>>>> I just tought that the DEFERRED probe may just do the trick i'm looking ways to implement the re-probeing... hmm. I try the deferred thing and check would that help.
>>>>>>>>>
>>>>>>>> Playing with options to work around the issue is of course a great way to
>>>>>>>> learn about the kernel. However it's questionable whether a workaround in
>>>>>>>> the driver is acceptable for dealing with the broken BIOS of exactly one
>>>>>>>>> 10 yrs old board (for which even a userspace workaround exists).
>>>>>>> problem recognized: libphy-module get's unloaded for some reason before r8169 driver loads -> missing lowlevel functionality -> not working driver. This only occurs at 1st load of module.. seeking solution.
>>>>>>>
>>>>>>>
>>>>>>> There is [last unloaded: libphy] entries in log BEFORE r8169 is probed first time.
>>>>>>>
>>>>>>>
>>>>>>> Any clue what is responsible for unloading to occur ?
>>>>>>>
>>>>>>>
>>>>>> Right now I'm debugging what is the reason, behind that the module starts to work properly only when
>>>>>>
>>>>>> unload & reload cycle is done.
>>>>>>
>>>>>>
>>>>>> The libphy is listed as loaded, but the check for low level read/write function is not set -> r8169 modules rlt_open() fails.
>>>>>>
>>>>>> See here:
>>>>>>
>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: ------------[ cut here ]------------
>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: read_page callback not available, PHY driver not loaded?
>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: WARNING: CPU: 3 PID: 787 at drivers/net/phy/phy-core.c:750 phy_save_page+0xb1/0xe3 [libph
>>>>>> y]
>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Modules linked in: cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel b
>>>>>> luetooth ecdh_generic rfkill ecc uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio videobuf2_v4l2 videobuf2_common snd_usbmidi_
>>>>>> lib videodev snd_rawmidi snd_seq_device mc input_leds joydev mousedev squashfs loop amdgpu snd_hda_codec_realtek gpu_sched i2c_algo_bit
>>>>>> ttm snd_hda_codec_generic drm_kms_helper edac_mce_amd ledtrig_audio cec rc_core kvm_amd drm ccp snd_hda_codec_hdmi agpgart rng_core kv
>>>>>> m snd_hda_intel syscopyarea sysfillrect ppdev sysimgblt snd_intel_dspcfg fb_sys_fops snd_hda_codec snd_hda_core snd_hwdep irqbypass wmi
>>>>>> _bmof snd_pcm snd_timer snd evdev pcspkr soundcore parport_pc parport sp5100_tco mac_hid i2c_piix4 k10temp acpi_cpufreq uinput crypto_u
>>>>>> ser ip_tables x_tables hid_generic usbhid hid ohci_pci virtio_net net_failover failover firewire_ohci firewire_core crc_itu_t pata_atii
>>>>>> xp ehci_pci ehci_hcd sr_mod cdrom ohci_hcd ata_generic pata_acpi pata_jmicron wmi floppy
>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: r8169 realtek libphy
>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: CPU: 3 PID: 787 Comm: NetworkManager Not tainted 5.7.0-1-raw #12
>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Hardware name: Gigabyte Technology Co., Ltd. GA-MA790FXT-UD5P/GA-MA790FXT-UD5P, BIOS F8l 07/15/2010
>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RIP: 0010:phy_save_page+0xb1/0xe3 [libphy]
>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Code: c8 82 11 c0 e8 06 28 ff cc 85 db 74 47 48 8b 85 48 03 00 00 48 83 b8 68 01 00 00 00 75 10 48 c7 c7 e8 82 11 c0 e8 a9 dd f7 cc <0f> 0b eb 26 48 c7 c7 52 78 11 c0 e8 99 dd f7 cc 0f 0b 48 8b 85 48
>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RSP: 0018:ffff962c408ef370 EFLAGS: 00010282
>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RDX: 0000000000000001 RSI: 0000000000000092 RDI: 00000000ffffffff
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: RBP: ffff8b1af3eb8800 R08: 00000000000004b3 R09: 0000000000000004
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffa1
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R13: 0000000000000002 R14: 0000000000000002 R15: ffff8b1af3eb8800
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: FS: 00007f07be5d4d80(0000) GS:ffff8b1af7cc0000(0000) knlGS:0000000000000000
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CR2: 000055b83aecb008 CR3: 00000002246b0000 CR4: 00000000000006e0
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: Call Trace:
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: phy_select_page+0x53/0x7a [libphy]
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: phy_write_paged+0x5c/0xa0 [libphy]
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl8168d_1_hw_phy_config+0x9d/0x210 [r8169]
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl8169_init_phy+0x19/0x110 [r8169]
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl_open+0x354/0x4d0 [r8169]
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_open+0xe0/0x170
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_change_flags+0x188/0x1e0
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: dev_change_flags+0x21/0x60
>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: do_setlink+0x78a/0xfd0
>>>>>>
>>>>>>
>>>>>> Something does not setup/register properly at first the way it should.
>>>>>>
>>>>>>
>>>>> I think i solved it: realtek (the phy driver) was missing device entry for the PHY ID reported by the NIC to match -> read_page and write_page function pointers should now be set. The generic PHY does not fill
>>>>>
>>>>> the driver's functionality to read or write pages. It happens to be so that the drivers for |RTL8211B Gigabit Ethernet seems to work just fine for my NIC's.
>>>> The analysis is wrong. The incorrect PHY ID is not root cause of the
>>>> problem, it's caused by a BIOS bug. It's not a valid PHY ID. If you want
>>>> to do something, then you could try to inject a PHY soft reset before
>>>> the MII bus is registered. This should be board-specific, e.g. using
>>>> dmi_check_system().
>>>
>>> Ok, i'll try that approach, thanks for the tip. Hmm, I'll do similar function mapping what the HW init/config function does determine
>>>
>>> function to use.
>>>
>>>
>>> I'll get back to you when I got something new developed.
>>>
>> Oujeah, now it works OK.. the soft reset was all it needed.
>>
>>
>> Here's the patch:
>>
>> From 06c5deacf3ca9f9258431756a41ff0ba1792f1f7 Mon Sep 17 00:00:00 2001
>> From: Lauri Jakku <lja@iki.fi>
>> Date: Thu, 16 Apr 2020 00:38:51 +0300
>> Subject: [PATCH] NET: r8169 driver identifying improvement.
>>
>> Trust device MAC enum + r8169d NIC soft reset
>> before configuration.
>>
>> This commit adds enumeration check and allows
>> driver to be slow to attach.
>>
>> Signed-off-by: Lauri Jakku <lja@iki.fi>
>> ---
>> drivers/net/ethernet/realtek/r8169_main.c | 24 +++--
>> .../net/ethernet/realtek/r8169_phy_config.c | 80 ++++++++++++++++
>> drivers/net/phy/phy-core.c | 91 ++++++++++++++++++-
>> 3 files changed, 182 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index bf5bf05970a2..a85764f6e448 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -640,7 +640,6 @@ MODULE_AUTHOR("Realtek and the Linux r8169 crew <netdev@vger.kernel.org>");
>> MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
>> module_param_named(debug, debug.msg_enable, int, 0);
>> MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
>> -MODULE_SOFTDEP("pre: realtek");
>> MODULE_LICENSE("GPL");
>> MODULE_FIRMWARE(FIRMWARE_8168D_1);
>> MODULE_FIRMWARE(FIRMWARE_8168D_2);
>> @@ -5172,13 +5171,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is loaded.
>> - */
>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> - mdiobus_unregister(new_bus);
>> - return -EUNATCH;
>> + } else {
>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>> +
>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>> + /* Most chip versions fail with the genphy driver.
>> + * Therefore ensure that the dedicated PHY driver is loaded.
>> + */
>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n");
>> + mdiobus_unregister(new_bus);
>> + return -EUNATCH;
>> + }
>> }
>>
>> /* PHY will be woken up in rtl_open() */
>> @@ -5513,6 +5517,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> rtl_chip_infos[chipset].name, dev->dev_addr, xid,
>> pci_irq_vector(pdev, 0));
>>
>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>> +
>> if (jumbo_max)
>> netif_info(tp, probe, dev,
>> "jumbo features [frames: %d bytes, tx checksumming: %s]\n",
>> @@ -5532,6 +5539,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> return rc;
>> }
>>
>> +
>> static struct pci_driver rtl8169_pci_driver = {
>> .name = MODULENAME,
>> .id_table = rtl8169_pci_tbl,
>> diff --git a/drivers/net/ethernet/realtek/r8169_phy_config.c b/drivers/net/ethernet/realtek/r8169_phy_config.c
>> index b73f7d023e99..73d604c7a8a8 100644
>> --- a/drivers/net/ethernet/realtek/r8169_phy_config.c
>> +++ b/drivers/net/ethernet/realtek/r8169_phy_config.c
>> @@ -1243,6 +1243,84 @@ static void rtl8125_2_hw_phy_config(struct rtl8169_private *tp,
>> rtl8125_config_eee_phy(phydev);
>> }
>>
>> +
>> +static void rtl8168d_hw_phy_pre_config_actions(struct rtl8169_private *tp,
>> + struct phy_device *phydev)
>> +{
>> + /* Reset the PHY before configuration. There is BIOS bug that gives
>> + * random PHY ID when device is not soft resetted first. --lja
>> + */
>> + genphy_soft_reset(phydev);
>> +}
>> +
>> +
>> +
>> +void r8169_hw_phy_pre_config_actions(struct rtl8169_private *tp, struct phy_device *phydev,
>> + enum mac_version ver)
>> +{
>> + static const rtl_phy_cfg_fct phy_pre_config_actions[] = {
>> + /* PCI devices. */
>> + [RTL_GIGA_MAC_VER_02] = NULL,
>> + [RTL_GIGA_MAC_VER_03] = NULL,
>> + [RTL_GIGA_MAC_VER_04] = NULL,
>> + [RTL_GIGA_MAC_VER_05] = NULL,
>> + [RTL_GIGA_MAC_VER_06] = NULL,
>> + /* PCI-E devices. */
>> + [RTL_GIGA_MAC_VER_07] = NULL,
>> + [RTL_GIGA_MAC_VER_08] = NULL,
>> + [RTL_GIGA_MAC_VER_09] = NULL,
>> + [RTL_GIGA_MAC_VER_10] = NULL,
>> + [RTL_GIGA_MAC_VER_11] = NULL,
>> + [RTL_GIGA_MAC_VER_12] = NULL,
>> + [RTL_GIGA_MAC_VER_13] = NULL,
>> + [RTL_GIGA_MAC_VER_14] = NULL,
>> + [RTL_GIGA_MAC_VER_15] = NULL,
>> + [RTL_GIGA_MAC_VER_16] = NULL,
>> + [RTL_GIGA_MAC_VER_17] = NULL,
>> + [RTL_GIGA_MAC_VER_18] = NULL,
>> + [RTL_GIGA_MAC_VER_19] = NULL,
>> + [RTL_GIGA_MAC_VER_20] = NULL,
>> + [RTL_GIGA_MAC_VER_21] = NULL,
>> + [RTL_GIGA_MAC_VER_22] = NULL,
>> + [RTL_GIGA_MAC_VER_23] = NULL,
>> + [RTL_GIGA_MAC_VER_24] = NULL,
>> + [RTL_GIGA_MAC_VER_25] = rtl8168d_hw_phy_pre_config_actions,
>> + [RTL_GIGA_MAC_VER_26] = rtl8168d_hw_phy_pre_config_actions,
>> + [RTL_GIGA_MAC_VER_27] = rtl8168d_hw_phy_pre_config_actions,
>> + [RTL_GIGA_MAC_VER_28] = rtl8168d_hw_phy_pre_config_actions,
>> + [RTL_GIGA_MAC_VER_29] = NULL,
>> + [RTL_GIGA_MAC_VER_30] = NULL,
>> + [RTL_GIGA_MAC_VER_31] = NULL,
>> + [RTL_GIGA_MAC_VER_32] = NULL,
>> + [RTL_GIGA_MAC_VER_33] = NULL,
>> + [RTL_GIGA_MAC_VER_34] = NULL,
>> + [RTL_GIGA_MAC_VER_35] = NULL,
>> + [RTL_GIGA_MAC_VER_36] = NULL,
>> + [RTL_GIGA_MAC_VER_37] = NULL,
>> + [RTL_GIGA_MAC_VER_38] = NULL,
>> + [RTL_GIGA_MAC_VER_39] = NULL,
>> + [RTL_GIGA_MAC_VER_40] = NULL,
>> + [RTL_GIGA_MAC_VER_41] = NULL,
>> + [RTL_GIGA_MAC_VER_42] = NULL,
>> + [RTL_GIGA_MAC_VER_43] = NULL,
>> + [RTL_GIGA_MAC_VER_44] = NULL,
>> + [RTL_GIGA_MAC_VER_45] = NULL,
>> + [RTL_GIGA_MAC_VER_46] = NULL,
>> + [RTL_GIGA_MAC_VER_47] = NULL,
>> + [RTL_GIGA_MAC_VER_48] = NULL,
>> + [RTL_GIGA_MAC_VER_49] = NULL,
>> + [RTL_GIGA_MAC_VER_50] = NULL,
>> + [RTL_GIGA_MAC_VER_51] = NULL,
>> + [RTL_GIGA_MAC_VER_52] = NULL,
>> + [RTL_GIGA_MAC_VER_60] = NULL,
>> + [RTL_GIGA_MAC_VER_61] = NULL,
>> + };
>> +
>> + if (phy_pre_config_actions[ver])
>> + phy_pre_config_actions[ver](tp, phydev);
>> +}
>> +
>> +
>> void r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device *phydev,
>> enum mac_version ver)
>> {
>> @@ -1303,6 +1381,8 @@ void r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device *phydev,
>> [RTL_GIGA_MAC_VER_60] = rtl8125_1_hw_phy_config,
>> [RTL_GIGA_MAC_VER_61] = rtl8125_2_hw_phy_config,
>> };
>> +
>> + r8169_hw_phy_pre_config_actions(tp, phydev);
>>
>> if (phy_configs[ver])
>> phy_configs[ver](tp, phydev);
>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>> index 66b8c61ca74c..b170185a1ed1 100644
>> --- a/drivers/net/phy/phy-core.c
>> +++ b/drivers/net/phy/phy-core.c
>> @@ -151,6 +151,25 @@ static const struct phy_setting settings[] = {
>> };
>> #undef PHY_SETTING
>>
>> +#ifdef DEBUG
>> +#define R8169_ATTACHED_PRINTK \
>> + printk("Phy is attached check %s @ %d: %d\n", \
>> + __FUNC__, __LINE__, is_attached_check);
>> +
>> +#else
>> +#define R8169_ATTACHED_PRINTK
>> +#endif
>> +
>> +#define PHY_NOT_ATTACHED_CHECK \
>> + { \
>> + void *attached_dev_ptr = (phydev) ? phydev->attached_dev : NULL; \
>> + int is_attached_check = (attached_dev_ptr != NULL) && \
>> + ((phydev) && (phydev->state >= PHY_READY)); \
>> + R8169_ATTACHED_PRINTK \
>> + if (! is_attached_check ) return -EOPNOTSUPP; \
>> + };
>> +
>> +
>> /**
>> * phy_lookup_setting - lookup a PHY setting
>> * @speed: speed to match
>> @@ -457,6 +476,9 @@ int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
>> {
>> int ret;
>>
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> phy_lock_mdio_bus(phydev);
>> ret = __phy_read_mmd(phydev, devad, regnum);
>> phy_unlock_mdio_bus(phydev);
>> @@ -479,6 +501,9 @@ int __phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
>> {
>> int ret;
>>
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> if (regnum > (u16)~0 || devad > 32)
>> return -EINVAL;
>>
>> @@ -518,6 +543,9 @@ int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
>> {
>> int ret;
>>
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> phy_lock_mdio_bus(phydev);
>> ret = __phy_write_mmd(phydev, devad, regnum, val);
>> phy_unlock_mdio_bus(phydev);
>> @@ -543,6 +571,10 @@ int phy_modify_changed(struct phy_device *phydev, u32 regnum, u16 mask, u16 set)
>> {
>> int ret;
>>
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> +
>> phy_lock_mdio_bus(phydev);
>> ret = __phy_modify_changed(phydev, regnum, mask, set);
>> phy_unlock_mdio_bus(phydev);
>> @@ -587,6 +619,9 @@ int phy_modify(struct phy_device *phydev, u32 regnum, u16 mask, u16 set)
>> {
>> int ret;
>>
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> phy_lock_mdio_bus(phydev);
>> ret = __phy_modify(phydev, regnum, mask, set);
>> phy_unlock_mdio_bus(phydev);
>> @@ -613,6 +648,9 @@ int __phy_modify_mmd_changed(struct phy_device *phydev, int devad, u32 regnum,
>> {
>> int new, ret;
>>
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> ret = __phy_read_mmd(phydev, devad, regnum);
>> if (ret < 0)
>> return ret;
>> @@ -646,6 +684,10 @@ int phy_modify_mmd_changed(struct phy_device *phydev, int devad, u32 regnum,
>> {
>> int ret;
>>
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> +
>> phy_lock_mdio_bus(phydev);
>> ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask, set);
>> phy_unlock_mdio_bus(phydev);
>> @@ -671,6 +713,9 @@ int __phy_modify_mmd(struct phy_device *phydev, int devad, u32 regnum,
>> {
>> int ret;
>>
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask, set);
>>
>> return ret < 0 ? ret : 0;
>> @@ -694,6 +739,9 @@ int phy_modify_mmd(struct phy_device *phydev, int devad, u32 regnum,
>> {
>> int ret;
>>
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> phy_lock_mdio_bus(phydev);
>> ret = __phy_modify_mmd(phydev, devad, regnum, mask, set);
>> phy_unlock_mdio_bus(phydev);
>> @@ -704,7 +752,11 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>
>> static int __phy_read_page(struct phy_device *phydev)
>> {
>> - if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>> +
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> + if (WARN(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>> return -EOPNOTSUPP;
>>
>> return phydev->drv->read_page(phydev);
>> @@ -712,12 +764,16 @@ static int __phy_read_page(struct phy_device *phydev)
>>
>> static int __phy_write_page(struct phy_device *phydev, int page)
>> {
>> - if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> + if (WARN(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>> return -EOPNOTSUPP;
>>
>> return phydev->drv->write_page(phydev, page);
>> }
>>
>> +
>> /**
>> * phy_save_page() - take the bus lock and save the current page
>> * @phydev: a pointer to a &struct phy_device
>> @@ -728,7 +784,11 @@ static int __phy_write_page(struct phy_device *phydev, int page)
>> */
>> int phy_save_page(struct phy_device *phydev)
>> {
>> - phy_lock_mdio_bus(phydev);
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> +
>> + phy_lock_mdio_bus(phydev);
>> return __phy_read_page(phydev);
>> }
>> EXPORT_SYMBOL_GPL(phy_save_page);
>> @@ -748,7 +808,10 @@ int phy_select_page(struct phy_device *phydev, int page)
>> {
>> int ret, oldpage;
>>
>> - oldpage = ret = phy_save_page(phydev);
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> + oldpage = ret = phy_save_page(phydev);
>> if (ret < 0)
>> return ret;
>>
>> @@ -782,6 +845,9 @@ int phy_restore_page(struct phy_device *phydev, int oldpage, int ret)
>> {
>> int r;
>>
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> if (oldpage >= 0) {
>> r = __phy_write_page(phydev, oldpage);
>>
>> @@ -812,6 +878,9 @@ EXPORT_SYMBOL_GPL(phy_restore_page);
>> int phy_read_paged(struct phy_device *phydev, int page, u32 regnum)
>> {
>> int ret = 0, oldpage;
>> +
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>>
>> oldpage = phy_select_page(phydev, page);
>> if (oldpage >= 0)
>> @@ -834,6 +903,10 @@ int phy_write_paged(struct phy_device *phydev, int page, u32 regnum, u16 val)
>> {
>> int ret = 0, oldpage;
>>
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> +
>> oldpage = phy_select_page(phydev, page);
>> if (oldpage >= 0)
>> ret = __phy_write(phydev, regnum, val);
>> @@ -856,6 +929,9 @@ int phy_modify_paged_changed(struct phy_device *phydev, int page, u32 regnum,
>> u16 mask, u16 set)
>> {
>> int ret = 0, oldpage;
>> +
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>>
>> oldpage = phy_select_page(phydev, page);
>> if (oldpage >= 0)
>> @@ -878,7 +954,12 @@ EXPORT_SYMBOL(phy_modify_paged_changed);
>> int phy_modify_paged(struct phy_device *phydev, int page, u32 regnum,
>> u16 mask, u16 set)
>> {
>> - int ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
>> + int ret = -1;
>> +
>> + /* If not attached, do nothing. */
>> + PHY_NOT_ATTACHED_CHECK;
>> +
>> + ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
>>
>> return ret < 0 ? ret : 0;
>> }
>
> here is the polished patch:
>
> From 6dd6f2813c543dc728efb8dca796bbbe870bd031 Mon Sep 17 00:00:00 2001
> From: Lauri Jakku <lja@iki.fi>
> Date: Thu, 16 Apr 2020 00:38:51 +0300
> Subject: [PATCH] NET: r8169 driver identifying improvement.
>
> Trust device MAC enum + r8169d NIC soft reset
> before configuration.
>
> This commit adds enumeration check and allows
> driver to be slow to attach.
>
> Signed-off-by: Lauri Jakku <lja@iki.fi>
> ---
> drivers/net/ethernet/realtek/r8169_main.c | 21 +++--
> .../net/ethernet/realtek/r8169_phy_config.c | 80 +++++++++++++++++++
> 2 files changed, 93 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index bf5bf05970a2..6828e755a460 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -640,7 +640,6 @@ MODULE_AUTHOR("Realtek and the Linux r8169 crew <netdev@vger.kernel.org>");
> MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
> module_param_named(debug, debug.msg_enable, int, 0);
> MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
> -MODULE_SOFTDEP("pre: realtek");
> MODULE_LICENSE("GPL");
> MODULE_FIRMWARE(FIRMWARE_8168D_1);
> MODULE_FIRMWARE(FIRMWARE_8168D_2);
> @@ -5172,13 +5171,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> if (!tp->phydev) {
> mdiobus_unregister(new_bus);
> return -ENODEV;
> - } else if (!tp->phydev->drv) {
> - /* Most chip versions fail with the genphy driver.
> - * Therefore ensure that the dedicated PHY driver is loaded.
> - */
> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
> - mdiobus_unregister(new_bus);
> - return -EUNATCH;
> + } else {
> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
> +
> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
> + /* Most chip versions fail with the genphy driver.
> + * Therefore ensure that the dedicated PHY driver is loaded.
> + */
> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n");
> + mdiobus_unregister(new_bus);
> + return -EUNATCH;
> + }
> }
>
> /* PHY will be woken up in rtl_open() */
> @@ -5532,6 +5536,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> return rc;
> }
>
> +
> static struct pci_driver rtl8169_pci_driver = {
> .name = MODULENAME,
> .id_table = rtl8169_pci_tbl,
> diff --git a/drivers/net/ethernet/realtek/r8169_phy_config.c b/drivers/net/ethernet/realtek/r8169_phy_config.c
> index b73f7d023e99..f13f68b79a92 100644
> --- a/drivers/net/ethernet/realtek/r8169_phy_config.c
> +++ b/drivers/net/ethernet/realtek/r8169_phy_config.c
> @@ -1243,6 +1243,84 @@ static void rtl8125_2_hw_phy_config(struct rtl8169_private *tp,
> rtl8125_config_eee_phy(phydev);
> }
>
> +
> +static void rtl8168d_hw_phy_pre_config_actions(struct rtl8169_private *tp,
> + struct phy_device *phydev)
> +{
> + /* Reset the PHY before configuration. There is BIOS bug that gives
> + * random PHY ID when device is not soft resetted first. --lja
> + */
> + genphy_soft_reset(phydev);
> +}
> +
> +
> +
> +void r8169_hw_phy_pre_config_actions(struct rtl8169_private *tp, struct phy_device *phydev,
> + enum mac_version ver)
> +{
> + static const rtl_phy_cfg_fct phy_pre_config_actions[] = {
> + /* PCI devices. */
> + [RTL_GIGA_MAC_VER_02] = NULL,
> + [RTL_GIGA_MAC_VER_03] = NULL,
> + [RTL_GIGA_MAC_VER_04] = NULL,
> + [RTL_GIGA_MAC_VER_05] = NULL,
> + [RTL_GIGA_MAC_VER_06] = NULL,
> + /* PCI-E devices. */
> + [RTL_GIGA_MAC_VER_07] = NULL,
> + [RTL_GIGA_MAC_VER_08] = NULL,
> + [RTL_GIGA_MAC_VER_09] = NULL,
> + [RTL_GIGA_MAC_VER_10] = NULL,
> + [RTL_GIGA_MAC_VER_11] = NULL,
> + [RTL_GIGA_MAC_VER_12] = NULL,
> + [RTL_GIGA_MAC_VER_13] = NULL,
> + [RTL_GIGA_MAC_VER_14] = NULL,
> + [RTL_GIGA_MAC_VER_15] = NULL,
> + [RTL_GIGA_MAC_VER_16] = NULL,
> + [RTL_GIGA_MAC_VER_17] = NULL,
> + [RTL_GIGA_MAC_VER_18] = NULL,
> + [RTL_GIGA_MAC_VER_19] = NULL,
> + [RTL_GIGA_MAC_VER_20] = NULL,
> + [RTL_GIGA_MAC_VER_21] = NULL,
> + [RTL_GIGA_MAC_VER_22] = NULL,
> + [RTL_GIGA_MAC_VER_23] = NULL,
> + [RTL_GIGA_MAC_VER_24] = NULL,
> + [RTL_GIGA_MAC_VER_25] = rtl8168d_hw_phy_pre_config_actions,
> + [RTL_GIGA_MAC_VER_26] = rtl8168d_hw_phy_pre_config_actions,
> + [RTL_GIGA_MAC_VER_27] = rtl8168d_hw_phy_pre_config_actions,
> + [RTL_GIGA_MAC_VER_28] = rtl8168d_hw_phy_pre_config_actions,
> + [RTL_GIGA_MAC_VER_29] = NULL,
> + [RTL_GIGA_MAC_VER_30] = NULL,
> + [RTL_GIGA_MAC_VER_31] = NULL,
> + [RTL_GIGA_MAC_VER_32] = NULL,
> + [RTL_GIGA_MAC_VER_33] = NULL,
> + [RTL_GIGA_MAC_VER_34] = NULL,
> + [RTL_GIGA_MAC_VER_35] = NULL,
> + [RTL_GIGA_MAC_VER_36] = NULL,
> + [RTL_GIGA_MAC_VER_37] = NULL,
> + [RTL_GIGA_MAC_VER_38] = NULL,
> + [RTL_GIGA_MAC_VER_39] = NULL,
> + [RTL_GIGA_MAC_VER_40] = NULL,
> + [RTL_GIGA_MAC_VER_41] = NULL,
> + [RTL_GIGA_MAC_VER_42] = NULL,
> + [RTL_GIGA_MAC_VER_43] = NULL,
> + [RTL_GIGA_MAC_VER_44] = NULL,
> + [RTL_GIGA_MAC_VER_45] = NULL,
> + [RTL_GIGA_MAC_VER_46] = NULL,
> + [RTL_GIGA_MAC_VER_47] = NULL,
> + [RTL_GIGA_MAC_VER_48] = NULL,
> + [RTL_GIGA_MAC_VER_49] = NULL,
> + [RTL_GIGA_MAC_VER_50] = NULL,
> + [RTL_GIGA_MAC_VER_51] = NULL,
> + [RTL_GIGA_MAC_VER_52] = NULL,
> + [RTL_GIGA_MAC_VER_60] = NULL,
> + [RTL_GIGA_MAC_VER_61] = NULL,
> + };
> +
> + if (phy_pre_config_actions[ver])
> + phy_pre_config_actions[ver](tp, phydev);
> +}
> +
> +
> void r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device *phydev,
> enum mac_version ver)
> {
> @@ -1304,6 +1382,8 @@ void r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device *phydev,
> [RTL_GIGA_MAC_VER_61] = rtl8125_2_hw_phy_config,
> };
>
> + r8169_hw_phy_pre_config_actions(tp, phydev, ver);
> +
> if (phy_configs[ver])
> phy_configs[ver](tp, phydev);
> }
The PHY ID is checked from devm_mdiobus_register(), you're way too late
with the soft reset. Also I said if a quirk is needed then it has to be
board-specific. This is not a problem of the chip version in general.
What you do in r8169_mdio_register() is simply wrong.
Last but not least you mix 100 different things in one patch.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-05-03 8:33 ` Heiner Kallweit
@ 2020-05-03 13:54 ` Lauri Jakku
2020-05-19 5:15 ` Lauri Jakku
2020-05-11 13:09 ` Lauri Jakku
1 sibling, 1 reply; 57+ messages in thread
From: Lauri Jakku @ 2020-05-03 13:54 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
On 3.5.2020 11.33, Heiner Kallweit wrote:
> On 03.05.2020 04:28, Lauri Jakku wrote:
>> Hi,
>>
>> On 3.5.2020 4.34, Lauri Jakku wrote:
>>> Hi,
>>>
>>>
>>> On 3.5.2020 3.11, Lauri Jakku wrote:
>>>> On 3.5.2020 2.15, Heiner Kallweit wrote:
>>>>> On 03.05.2020 00:42, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2.5.2020 20.56, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 1.5.2020 22.12, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>> On 19.4.2020 19.00, Heiner Kallweit wrote:
>>>>>>>>> On 19.04.2020 18:49, Lauri Jakku wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>>>>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>>>>>>>>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>>>>>>>>>>>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>>>>>>>>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>>>>>>>>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>>>>>>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
>>>>>>>>>>>>>>>>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>>>>>>>>>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then you have the same
>>>>>>>>>>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: MAC version: 23
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> .. after module unload & load cycle:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> it seem to be the case that the phy_id chances onetime, then stays the same. I'll do few shutdowns and see
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is there a pattern at all .. next i'm going to try how it behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The BIOS downgrade: I'd like to solve this without downgrading BIOS. If I can't, then I'll do systemd-service that
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What i've gathered samples now, there is three values for PHY ID:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep "PHY ver"
>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I dont know are those hard coded or what, and are they device specific how much.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> i haven't coldbooted things up, that may be that something to check do they vary how per coldboot.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I check the ID, and revert all other changes, and check how it is working after adding the PHY id to list.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> What i've now learned: the patch + script + journald services -> Results working network, but it is still a workaround.
>>>>>>>>>>>>>
>>>>>>>>>>>> Following patch trusts the MAC version, another thing witch could help is to derive method to do 2dn pass of the probeing:
>>>>>>>>>>>>
>>>>>>>>>>>> if specific MAC version is found.
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>> index acd122a88d4a..62b37a1abc24 100644
>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>>>>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>>>>>> - */
>>>>>>>>>>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>>>> - mdiobus_unregister(new_bus);
>>>>>>>>>>>> - return -EUNATCH;
>>>>>>>>>>>> + } else {
>>>>>>>>>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>>>>>>>>>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>>>>>>>>>>> +
>>>>>>>>>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>> + /* Most chip versions fail with the genphy driver.
>>>>>>>>>>>> + * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>>>>>> + */
>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n", tp->phydev->phy_id);
>>>>>>>>>>>> + mdiobus_unregister(new_bus);
>>>>>>>>>>>> + return -EUNATCH;
>>>>>>>>>>>> + }
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>>>>>>>
>>>>>>>>>>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's updated.. and now up'n'running. There is one (WARN_ONCE) stack trace coming from driver, i think i tinker with it next, with above patch the network devices shows up and they can be configured.
>>>>>>>>>>>
>>>>>>>>>> I tought to ask first, before going to make new probe_type for errorneus hw (propetype + retry counter) to do re-probe if requested, N times. Or should the r8169_main.c return deferred probe on error on some MAC enums ? Which approach is design-wise sound ?
>>>>>>>>>>
>>>>>>>>>> I just tought that the DEFERRED probe may just do the trick i'm looking ways to implement the re-probeing... hmm. I try the deferred thing and check would that help.
>>>>>>>>>>
>>>>>>>>> Playing with options to work around the issue is of course a great way to
>>>>>>>>> learn about the kernel. However it's questionable whether a workaround in
>>>>>>>>> the driver is acceptable for dealing with the broken BIOS of exactly one
>>>>>>>>>> 10 yrs old board (for which even a userspace workaround exists).
>>>>>>>> problem recognized: libphy-module get's unloaded for some reason before r8169 driver loads -> missing lowlevel functionality -> not working driver. This only occurs at 1st load of module.. seeking solution.
>>>>>>>>
>>>>>>>>
>>>>>>>> There is [last unloaded: libphy] entries in log BEFORE r8169 is probed first time.
>>>>>>>>
>>>>>>>>
>>>>>>>> Any clue what is responsible for unloading to occur ?
>>>>>>>>
>>>>>>>>
>>>>>>> Right now I'm debugging what is the reason, behind that the module starts to work properly only when
>>>>>>>
>>>>>>> unload & reload cycle is done.
>>>>>>>
>>>>>>>
>>>>>>> The libphy is listed as loaded, but the check for low level read/write function is not set -> r8169 modules rlt_open() fails.
>>>>>>>
>>>>>>> See here:
>>>>>>>
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: ------------[ cut here ]------------
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: read_page callback not available, PHY driver not loaded?
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: WARNING: CPU: 3 PID: 787 at drivers/net/phy/phy-core.c:750 phy_save_page+0xb1/0xe3 [libph
>>>>>>> y]
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Modules linked in: cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel b
>>>>>>> luetooth ecdh_generic rfkill ecc uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio videobuf2_v4l2 videobuf2_common snd_usbmidi_
>>>>>>> lib videodev snd_rawmidi snd_seq_device mc input_leds joydev mousedev squashfs loop amdgpu snd_hda_codec_realtek gpu_sched i2c_algo_bit
>>>>>>> ttm snd_hda_codec_generic drm_kms_helper edac_mce_amd ledtrig_audio cec rc_core kvm_amd drm ccp snd_hda_codec_hdmi agpgart rng_core kv
>>>>>>> m snd_hda_intel syscopyarea sysfillrect ppdev sysimgblt snd_intel_dspcfg fb_sys_fops snd_hda_codec snd_hda_core snd_hwdep irqbypass wmi
>>>>>>> _bmof snd_pcm snd_timer snd evdev pcspkr soundcore parport_pc parport sp5100_tco mac_hid i2c_piix4 k10temp acpi_cpufreq uinput crypto_u
>>>>>>> ser ip_tables x_tables hid_generic usbhid hid ohci_pci virtio_net net_failover failover firewire_ohci firewire_core crc_itu_t pata_atii
>>>>>>> xp ehci_pci ehci_hcd sr_mod cdrom ohci_hcd ata_generic pata_acpi pata_jmicron wmi floppy
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: r8169 realtek libphy
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: CPU: 3 PID: 787 Comm: NetworkManager Not tainted 5.7.0-1-raw #12
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Hardware name: Gigabyte Technology Co., Ltd. GA-MA790FXT-UD5P/GA-MA790FXT-UD5P, BIOS F8l 07/15/2010
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RIP: 0010:phy_save_page+0xb1/0xe3 [libphy]
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Code: c8 82 11 c0 e8 06 28 ff cc 85 db 74 47 48 8b 85 48 03 00 00 48 83 b8 68 01 00 00 00 75 10 48 c7 c7 e8 82 11 c0 e8 a9 dd f7 cc <0f> 0b eb 26 48 c7 c7 52 78 11 c0 e8 99 dd f7 cc 0f 0b 48 8b 85 48
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RSP: 0018:ffff962c408ef370 EFLAGS: 00010282
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RDX: 0000000000000001 RSI: 0000000000000092 RDI: 00000000ffffffff
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: RBP: ffff8b1af3eb8800 R08: 00000000000004b3 R09: 0000000000000004
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffa1
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R13: 0000000000000002 R14: 0000000000000002 R15: ffff8b1af3eb8800
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: FS: 00007f07be5d4d80(0000) GS:ffff8b1af7cc0000(0000) knlGS:0000000000000000
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CR2: 000055b83aecb008 CR3: 00000002246b0000 CR4: 00000000000006e0
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: Call Trace:
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: phy_select_page+0x53/0x7a [libphy]
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: phy_write_paged+0x5c/0xa0 [libphy]
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl8168d_1_hw_phy_config+0x9d/0x210 [r8169]
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl8169_init_phy+0x19/0x110 [r8169]
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl_open+0x354/0x4d0 [r8169]
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_open+0xe0/0x170
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_change_flags+0x188/0x1e0
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: dev_change_flags+0x21/0x60
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: do_setlink+0x78a/0xfd0
>>>>>>>
>>>>>>>
>>>>>>> Something does not setup/register properly at first the way it should.
>>>>>>>
>>>>>>>
>>>>>> I think i solved it: realtek (the phy driver) was missing device entry for the PHY ID reported by the NIC to match -> read_page and write_page function pointers should now be set. The generic PHY does not fill
>>>>>>
>>>>>> the driver's functionality to read or write pages. It happens to be so that the drivers for |RTL8211B Gigabit Ethernet seems to work just fine for my NIC's.
>>>>> The analysis is wrong. The incorrect PHY ID is not root cause of the
>>>>> problem, it's caused by a BIOS bug. It's not a valid PHY ID. If you want
>>>>> to do something, then you could try to inject a PHY soft reset before
>>>>> the MII bus is registered. This should be board-specific, e.g. using
>>>>> dmi_check_system().
>>>> Ok, i'll try that approach, thanks for the tip. Hmm, I'll do similar function mapping what the HW init/config function does determine
>>>>
>>>> function to use.
>>>>
>>>>
>>>> I'll get back to you when I got something new developed.
>>>>
>>> Oujeah, now it works OK.. the soft reset was all it needed.
>>>
>>>
>>> Here's the patch:
>>>
>>> From 06c5deacf3ca9f9258431756a41ff0ba1792f1f7 Mon Sep 17 00:00:00 2001
>>> From: Lauri Jakku <lja@iki.fi>
>>> Date: Thu, 16 Apr 2020 00:38:51 +0300
>>> Subject: [PATCH] NET: r8169 driver identifying improvement.
>>>
>>> Trust device MAC enum + r8169d NIC soft reset
>>> before configuration.
>>>
>>> This commit adds enumeration check and allows
>>> driver to be slow to attach.
>>>
>>> Signed-off-by: Lauri Jakku <lja@iki.fi>
>>> ---
>>> drivers/net/ethernet/realtek/r8169_main.c | 24 +++--
>>> .../net/ethernet/realtek/r8169_phy_config.c | 80 ++++++++++++++++
>>> drivers/net/phy/phy-core.c | 91 ++++++++++++++++++-
>>> 3 files changed, 182 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>> index bf5bf05970a2..a85764f6e448 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>> @@ -640,7 +640,6 @@ MODULE_AUTHOR("Realtek and the Linux r8169 crew <netdev@vger.kernel.org>");
>>> MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
>>> module_param_named(debug, debug.msg_enable, int, 0);
>>> MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
>>> -MODULE_SOFTDEP("pre: realtek");
>>> MODULE_LICENSE("GPL");
>>> MODULE_FIRMWARE(FIRMWARE_8168D_1);
>>> MODULE_FIRMWARE(FIRMWARE_8168D_2);
>>> @@ -5172,13 +5171,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>> if (!tp->phydev) {
>>> mdiobus_unregister(new_bus);
>>> return -ENODEV;
>>> - } else if (!tp->phydev->drv) {
>>> - /* Most chip versions fail with the genphy driver.
>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>> - */
>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>> - mdiobus_unregister(new_bus);
>>> - return -EUNATCH;
>>> + } else {
>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>> +
>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>> + /* Most chip versions fail with the genphy driver.
>>> + * Therefore ensure that the dedicated PHY driver is loaded.
>>> + */
>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n");
>>> + mdiobus_unregister(new_bus);
>>> + return -EUNATCH;
>>> + }
>>> }
>>>
>>> /* PHY will be woken up in rtl_open() */
>>> @@ -5513,6 +5517,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> rtl_chip_infos[chipset].name, dev->dev_addr, xid,
>>> pci_irq_vector(pdev, 0));
>>>
>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>> +
>>> if (jumbo_max)
>>> netif_info(tp, probe, dev,
>>> "jumbo features [frames: %d bytes, tx checksumming: %s]\n",
>>> @@ -5532,6 +5539,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> return rc;
>>> }
>>>
>>> +
>>> static struct pci_driver rtl8169_pci_driver = {
>>> .name = MODULENAME,
>>> .id_table = rtl8169_pci_tbl,
>>> diff --git a/drivers/net/ethernet/realtek/r8169_phy_config.c b/drivers/net/ethernet/realtek/r8169_phy_config.c
>>> index b73f7d023e99..73d604c7a8a8 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_phy_config.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_phy_config.c
>>> @@ -1243,6 +1243,84 @@ static void rtl8125_2_hw_phy_config(struct rtl8169_private *tp,
>>> rtl8125_config_eee_phy(phydev);
>>> }
>>>
>>> +
>>> +static void rtl8168d_hw_phy_pre_config_actions(struct rtl8169_private *tp,
>>> + struct phy_device *phydev)
>>> +{
>>> + /* Reset the PHY before configuration. There is BIOS bug that gives
>>> + * random PHY ID when device is not soft resetted first. --lja
>>> + */
>>> + genphy_soft_reset(phydev);
>>> +}
>>> +
>>> +
>>> +
>>> +void r8169_hw_phy_pre_config_actions(struct rtl8169_private *tp, struct phy_device *phydev,
>>> + enum mac_version ver)
>>> +{
>>> + static const rtl_phy_cfg_fct phy_pre_config_actions[] = {
>>> + /* PCI devices. */
>>> + [RTL_GIGA_MAC_VER_02] = NULL,
>>> + [RTL_GIGA_MAC_VER_03] = NULL,
>>> + [RTL_GIGA_MAC_VER_04] = NULL,
>>> + [RTL_GIGA_MAC_VER_05] = NULL,
>>> + [RTL_GIGA_MAC_VER_06] = NULL,
>>> + /* PCI-E devices. */
>>> + [RTL_GIGA_MAC_VER_07] = NULL,
>>> + [RTL_GIGA_MAC_VER_08] = NULL,
>>> + [RTL_GIGA_MAC_VER_09] = NULL,
>>> + [RTL_GIGA_MAC_VER_10] = NULL,
>>> + [RTL_GIGA_MAC_VER_11] = NULL,
>>> + [RTL_GIGA_MAC_VER_12] = NULL,
>>> + [RTL_GIGA_MAC_VER_13] = NULL,
>>> + [RTL_GIGA_MAC_VER_14] = NULL,
>>> + [RTL_GIGA_MAC_VER_15] = NULL,
>>> + [RTL_GIGA_MAC_VER_16] = NULL,
>>> + [RTL_GIGA_MAC_VER_17] = NULL,
>>> + [RTL_GIGA_MAC_VER_18] = NULL,
>>> + [RTL_GIGA_MAC_VER_19] = NULL,
>>> + [RTL_GIGA_MAC_VER_20] = NULL,
>>> + [RTL_GIGA_MAC_VER_21] = NULL,
>>> + [RTL_GIGA_MAC_VER_22] = NULL,
>>> + [RTL_GIGA_MAC_VER_23] = NULL,
>>> + [RTL_GIGA_MAC_VER_24] = NULL,
>>> + [RTL_GIGA_MAC_VER_25] = rtl8168d_hw_phy_pre_config_actions,
>>> + [RTL_GIGA_MAC_VER_26] = rtl8168d_hw_phy_pre_config_actions,
>>> + [RTL_GIGA_MAC_VER_27] = rtl8168d_hw_phy_pre_config_actions,
>>> + [RTL_GIGA_MAC_VER_28] = rtl8168d_hw_phy_pre_config_actions,
>>> + [RTL_GIGA_MAC_VER_29] = NULL,
>>> + [RTL_GIGA_MAC_VER_30] = NULL,
>>> + [RTL_GIGA_MAC_VER_31] = NULL,
>>> + [RTL_GIGA_MAC_VER_32] = NULL,
>>> + [RTL_GIGA_MAC_VER_33] = NULL,
>>> + [RTL_GIGA_MAC_VER_34] = NULL,
>>> + [RTL_GIGA_MAC_VER_35] = NULL,
>>> + [RTL_GIGA_MAC_VER_36] = NULL,
>>> + [RTL_GIGA_MAC_VER_37] = NULL,
>>> + [RTL_GIGA_MAC_VER_38] = NULL,
>>> + [RTL_GIGA_MAC_VER_39] = NULL,
>>> + [RTL_GIGA_MAC_VER_40] = NULL,
>>> + [RTL_GIGA_MAC_VER_41] = NULL,
>>> + [RTL_GIGA_MAC_VER_42] = NULL,
>>> + [RTL_GIGA_MAC_VER_43] = NULL,
>>> + [RTL_GIGA_MAC_VER_44] = NULL,
>>> + [RTL_GIGA_MAC_VER_45] = NULL,
>>> + [RTL_GIGA_MAC_VER_46] = NULL,
>>> + [RTL_GIGA_MAC_VER_47] = NULL,
>>> + [RTL_GIGA_MAC_VER_48] = NULL,
>>> + [RTL_GIGA_MAC_VER_49] = NULL,
>>> + [RTL_GIGA_MAC_VER_50] = NULL,
>>> + [RTL_GIGA_MAC_VER_51] = NULL,
>>> + [RTL_GIGA_MAC_VER_52] = NULL,
>>> + [RTL_GIGA_MAC_VER_60] = NULL,
>>> + [RTL_GIGA_MAC_VER_61] = NULL,
>>> + };
>>> +
>>> + if (phy_pre_config_actions[ver])
>>> + phy_pre_config_actions[ver](tp, phydev);
>>> +}
>>> +
>>> +
>>> void r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device *phydev,
>>> enum mac_version ver)
>>> {
>>> @@ -1303,6 +1381,8 @@ void r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device *phydev,
>>> [RTL_GIGA_MAC_VER_60] = rtl8125_1_hw_phy_config,
>>> [RTL_GIGA_MAC_VER_61] = rtl8125_2_hw_phy_config,
>>> };
>>> +
>>> + r8169_hw_phy_pre_config_actions(tp, phydev);
>>>
>>> if (phy_configs[ver])
>>> phy_configs[ver](tp, phydev);
>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>> index 66b8c61ca74c..b170185a1ed1 100644
>>> --- a/drivers/net/phy/phy-core.c
>>> +++ b/drivers/net/phy/phy-core.c
>>> @@ -151,6 +151,25 @@ static const struct phy_setting settings[] = {
>>> };
>>> #undef PHY_SETTING
>>>
>>> +#ifdef DEBUG
>>> +#define R8169_ATTACHED_PRINTK \
>>> + printk("Phy is attached check %s @ %d: %d\n", \
>>> + __FUNC__, __LINE__, is_attached_check);
>>> +
>>> +#else
>>> +#define R8169_ATTACHED_PRINTK
>>> +#endif
>>> +
>>> +#define PHY_NOT_ATTACHED_CHECK \
>>> + { \
>>> + void *attached_dev_ptr = (phydev) ? phydev->attached_dev : NULL; \
>>> + int is_attached_check = (attached_dev_ptr != NULL) && \
>>> + ((phydev) && (phydev->state >= PHY_READY)); \
>>> + R8169_ATTACHED_PRINTK \
>>> + if (! is_attached_check ) return -EOPNOTSUPP; \
>>> + };
>>> +
>>> +
>>> /**
>>> * phy_lookup_setting - lookup a PHY setting
>>> * @speed: speed to match
>>> @@ -457,6 +476,9 @@ int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> phy_lock_mdio_bus(phydev);
>>> ret = __phy_read_mmd(phydev, devad, regnum);
>>> phy_unlock_mdio_bus(phydev);
>>> @@ -479,6 +501,9 @@ int __phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> if (regnum > (u16)~0 || devad > 32)
>>> return -EINVAL;
>>>
>>> @@ -518,6 +543,9 @@ int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> phy_lock_mdio_bus(phydev);
>>> ret = __phy_write_mmd(phydev, devad, regnum, val);
>>> phy_unlock_mdio_bus(phydev);
>>> @@ -543,6 +571,10 @@ int phy_modify_changed(struct phy_device *phydev, u32 regnum, u16 mask, u16 set)
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> +
>>> phy_lock_mdio_bus(phydev);
>>> ret = __phy_modify_changed(phydev, regnum, mask, set);
>>> phy_unlock_mdio_bus(phydev);
>>> @@ -587,6 +619,9 @@ int phy_modify(struct phy_device *phydev, u32 regnum, u16 mask, u16 set)
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> phy_lock_mdio_bus(phydev);
>>> ret = __phy_modify(phydev, regnum, mask, set);
>>> phy_unlock_mdio_bus(phydev);
>>> @@ -613,6 +648,9 @@ int __phy_modify_mmd_changed(struct phy_device *phydev, int devad, u32 regnum,
>>> {
>>> int new, ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> ret = __phy_read_mmd(phydev, devad, regnum);
>>> if (ret < 0)
>>> return ret;
>>> @@ -646,6 +684,10 @@ int phy_modify_mmd_changed(struct phy_device *phydev, int devad, u32 regnum,
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> +
>>> phy_lock_mdio_bus(phydev);
>>> ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask, set);
>>> phy_unlock_mdio_bus(phydev);
>>> @@ -671,6 +713,9 @@ int __phy_modify_mmd(struct phy_device *phydev, int devad, u32 regnum,
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask, set);
>>>
>>> return ret < 0 ? ret : 0;
>>> @@ -694,6 +739,9 @@ int phy_modify_mmd(struct phy_device *phydev, int devad, u32 regnum,
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> phy_lock_mdio_bus(phydev);
>>> ret = __phy_modify_mmd(phydev, devad, regnum, mask, set);
>>> phy_unlock_mdio_bus(phydev);
>>> @@ -704,7 +752,11 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>
>>> static int __phy_read_page(struct phy_device *phydev)
>>> {
>>> - if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>> +
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> + if (WARN(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>> return -EOPNOTSUPP;
>>>
>>> return phydev->drv->read_page(phydev);
>>> @@ -712,12 +764,16 @@ static int __phy_read_page(struct phy_device *phydev)
>>>
>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>> {
>>> - if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> + if (WARN(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>> return -EOPNOTSUPP;
>>>
>>> return phydev->drv->write_page(phydev, page);
>>> }
>>>
>>> +
>>> /**
>>> * phy_save_page() - take the bus lock and save the current page
>>> * @phydev: a pointer to a &struct phy_device
>>> @@ -728,7 +784,11 @@ static int __phy_write_page(struct phy_device *phydev, int page)
>>> */
>>> int phy_save_page(struct phy_device *phydev)
>>> {
>>> - phy_lock_mdio_bus(phydev);
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> +
>>> + phy_lock_mdio_bus(phydev);
>>> return __phy_read_page(phydev);
>>> }
>>> EXPORT_SYMBOL_GPL(phy_save_page);
>>> @@ -748,7 +808,10 @@ int phy_select_page(struct phy_device *phydev, int page)
>>> {
>>> int ret, oldpage;
>>>
>>> - oldpage = ret = phy_save_page(phydev);
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> + oldpage = ret = phy_save_page(phydev);
>>> if (ret < 0)
>>> return ret;
>>>
>>> @@ -782,6 +845,9 @@ int phy_restore_page(struct phy_device *phydev, int oldpage, int ret)
>>> {
>>> int r;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> if (oldpage >= 0) {
>>> r = __phy_write_page(phydev, oldpage);
>>>
>>> @@ -812,6 +878,9 @@ EXPORT_SYMBOL_GPL(phy_restore_page);
>>> int phy_read_paged(struct phy_device *phydev, int page, u32 regnum)
>>> {
>>> int ret = 0, oldpage;
>>> +
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>>
>>> oldpage = phy_select_page(phydev, page);
>>> if (oldpage >= 0)
>>> @@ -834,6 +903,10 @@ int phy_write_paged(struct phy_device *phydev, int page, u32 regnum, u16 val)
>>> {
>>> int ret = 0, oldpage;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> +
>>> oldpage = phy_select_page(phydev, page);
>>> if (oldpage >= 0)
>>> ret = __phy_write(phydev, regnum, val);
>>> @@ -856,6 +929,9 @@ int phy_modify_paged_changed(struct phy_device *phydev, int page, u32 regnum,
>>> u16 mask, u16 set)
>>> {
>>> int ret = 0, oldpage;
>>> +
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>>
>>> oldpage = phy_select_page(phydev, page);
>>> if (oldpage >= 0)
>>> @@ -878,7 +954,12 @@ EXPORT_SYMBOL(phy_modify_paged_changed);
>>> int phy_modify_paged(struct phy_device *phydev, int page, u32 regnum,
>>> u16 mask, u16 set)
>>> {
>>> - int ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
>>> + int ret = -1;
>>> +
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> + ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
>>>
>>> return ret < 0 ? ret : 0;
>>> }
>> here is the polished patch:
>>
>> From 6dd6f2813c543dc728efb8dca796bbbe870bd031 Mon Sep 17 00:00:00 2001
>> From: Lauri Jakku <lja@iki.fi>
>> Date: Thu, 16 Apr 2020 00:38:51 +0300
>> Subject: [PATCH] NET: r8169 driver identifying improvement.
>>
>> Trust device MAC enum + r8169d NIC soft reset
>> before configuration.
>>
>> This commit adds enumeration check and allows
>> driver to be slow to attach.
>>
>> Signed-off-by: Lauri Jakku <lja@iki.fi>
>> ---
>> drivers/net/ethernet/realtek/r8169_main.c | 21 +++--
>> .../net/ethernet/realtek/r8169_phy_config.c | 80 +++++++++++++++++++
>> 2 files changed, 93 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index bf5bf05970a2..6828e755a460 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -640,7 +640,6 @@ MODULE_AUTHOR("Realtek and the Linux r8169 crew <netdev@vger.kernel.org>");
>> MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
>> module_param_named(debug, debug.msg_enable, int, 0);
>> MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
>> -MODULE_SOFTDEP("pre: realtek");
>> MODULE_LICENSE("GPL");
>> MODULE_FIRMWARE(FIRMWARE_8168D_1);
>> MODULE_FIRMWARE(FIRMWARE_8168D_2);
>> @@ -5172,13 +5171,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is loaded.
>> - */
>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> - mdiobus_unregister(new_bus);
>> - return -EUNATCH;
>> + } else {
>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>> +
>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>> + /* Most chip versions fail with the genphy driver.
>> + * Therefore ensure that the dedicated PHY driver is loaded.
>> + */
>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n");
>> + mdiobus_unregister(new_bus);
>> + return -EUNATCH;
>> + }
>> }
>>
>> /* PHY will be woken up in rtl_open() */
>> @@ -5532,6 +5536,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> return rc;
>> }
>>
>> +
>> static struct pci_driver rtl8169_pci_driver = {
>> .name = MODULENAME,
>> .id_table = rtl8169_pci_tbl,
>> diff --git a/drivers/net/ethernet/realtek/r8169_phy_config.c b/drivers/net/ethernet/realtek/r8169_phy_config.c
>> index b73f7d023e99..f13f68b79a92 100644
>> --- a/drivers/net/ethernet/realtek/r8169_phy_config.c
>> +++ b/drivers/net/ethernet/realtek/r8169_phy_config.c
>> @@ -1243,6 +1243,84 @@ static void rtl8125_2_hw_phy_config(struct rtl8169_private *tp,
>> rtl8125_config_eee_phy(phydev);
>> }
>>
>> +
>> +static void rtl8168d_hw_phy_pre_config_actions(struct rtl8169_private *tp,
>> + struct phy_device *phydev)
>> +{
>> + /* Reset the PHY before configuration. There is BIOS bug that gives
>> + * random PHY ID when device is not soft resetted first. --lja
>> + */
>> + genphy_soft_reset(phydev);
>> +}
>> +
>> +
>> +
>> +void r8169_hw_phy_pre_config_actions(struct rtl8169_private *tp, struct phy_device *phydev,
>> + enum mac_version ver)
>> +{
>> + static const rtl_phy_cfg_fct phy_pre_config_actions[] = {
>> + /* PCI devices. */
>> + [RTL_GIGA_MAC_VER_02] = NULL,
>> + [RTL_GIGA_MAC_VER_03] = NULL,
>> + [RTL_GIGA_MAC_VER_04] = NULL,
>> + [RTL_GIGA_MAC_VER_05] = NULL,
>> + [RTL_GIGA_MAC_VER_06] = NULL,
>> + /* PCI-E devices. */
>> + [RTL_GIGA_MAC_VER_07] = NULL,
>> + [RTL_GIGA_MAC_VER_08] = NULL,
>> + [RTL_GIGA_MAC_VER_09] = NULL,
>> + [RTL_GIGA_MAC_VER_10] = NULL,
>> + [RTL_GIGA_MAC_VER_11] = NULL,
>> + [RTL_GIGA_MAC_VER_12] = NULL,
>> + [RTL_GIGA_MAC_VER_13] = NULL,
>> + [RTL_GIGA_MAC_VER_14] = NULL,
>> + [RTL_GIGA_MAC_VER_15] = NULL,
>> + [RTL_GIGA_MAC_VER_16] = NULL,
>> + [RTL_GIGA_MAC_VER_17] = NULL,
>> + [RTL_GIGA_MAC_VER_18] = NULL,
>> + [RTL_GIGA_MAC_VER_19] = NULL,
>> + [RTL_GIGA_MAC_VER_20] = NULL,
>> + [RTL_GIGA_MAC_VER_21] = NULL,
>> + [RTL_GIGA_MAC_VER_22] = NULL,
>> + [RTL_GIGA_MAC_VER_23] = NULL,
>> + [RTL_GIGA_MAC_VER_24] = NULL,
>> + [RTL_GIGA_MAC_VER_25] = rtl8168d_hw_phy_pre_config_actions,
>> + [RTL_GIGA_MAC_VER_26] = rtl8168d_hw_phy_pre_config_actions,
>> + [RTL_GIGA_MAC_VER_27] = rtl8168d_hw_phy_pre_config_actions,
>> + [RTL_GIGA_MAC_VER_28] = rtl8168d_hw_phy_pre_config_actions,
>> + [RTL_GIGA_MAC_VER_29] = NULL,
>> + [RTL_GIGA_MAC_VER_30] = NULL,
>> + [RTL_GIGA_MAC_VER_31] = NULL,
>> + [RTL_GIGA_MAC_VER_32] = NULL,
>> + [RTL_GIGA_MAC_VER_33] = NULL,
>> + [RTL_GIGA_MAC_VER_34] = NULL,
>> + [RTL_GIGA_MAC_VER_35] = NULL,
>> + [RTL_GIGA_MAC_VER_36] = NULL,
>> + [RTL_GIGA_MAC_VER_37] = NULL,
>> + [RTL_GIGA_MAC_VER_38] = NULL,
>> + [RTL_GIGA_MAC_VER_39] = NULL,
>> + [RTL_GIGA_MAC_VER_40] = NULL,
>> + [RTL_GIGA_MAC_VER_41] = NULL,
>> + [RTL_GIGA_MAC_VER_42] = NULL,
>> + [RTL_GIGA_MAC_VER_43] = NULL,
>> + [RTL_GIGA_MAC_VER_44] = NULL,
>> + [RTL_GIGA_MAC_VER_45] = NULL,
>> + [RTL_GIGA_MAC_VER_46] = NULL,
>> + [RTL_GIGA_MAC_VER_47] = NULL,
>> + [RTL_GIGA_MAC_VER_48] = NULL,
>> + [RTL_GIGA_MAC_VER_49] = NULL,
>> + [RTL_GIGA_MAC_VER_50] = NULL,
>> + [RTL_GIGA_MAC_VER_51] = NULL,
>> + [RTL_GIGA_MAC_VER_52] = NULL,
>> + [RTL_GIGA_MAC_VER_60] = NULL,
>> + [RTL_GIGA_MAC_VER_61] = NULL,
>> + };
>> +
>> + if (phy_pre_config_actions[ver])
>> + phy_pre_config_actions[ver](tp, phydev);
>> +}
>> +
>> +
>> void r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device *phydev,
>> enum mac_version ver)
>> {
>> @@ -1304,6 +1382,8 @@ void r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device *phydev,
>> [RTL_GIGA_MAC_VER_61] = rtl8125_2_hw_phy_config,
>> };
>>
>> + r8169_hw_phy_pre_config_actions(tp, phydev, ver);
>> +
>> if (phy_configs[ver])
>> phy_configs[ver](tp, phydev);
>> }
> The PHY ID is checked from devm_mdiobus_register(), you're way too late
> with the soft reset. Also I said if a quirk is needed then it has to be
> board-specific. This is not a problem of the chip version in general.
> What you do in r8169_mdio_register() is simply wrong.
> Last but not least you mix 100 different things in one patch.
There is no devm_mdiobus_register() and the (pre) configuration is done
way before any registering is done? I check few boots and clean up the
patch with check tool, and post then.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-05-03 8:33 ` Heiner Kallweit
2020-05-03 13:54 ` Lauri Jakku
@ 2020-05-11 13:09 ` Lauri Jakku
1 sibling, 0 replies; 57+ messages in thread
From: Lauri Jakku @ 2020-05-11 13:09 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
On 3.5.2020 11.33, Heiner Kallweit wrote:
> On 03.05.2020 04:28, Lauri Jakku wrote:
>> Hi,
>>
>> On 3.5.2020 4.34, Lauri Jakku wrote:
>>> Hi,
>>>
>>>
>>> On 3.5.2020 3.11, Lauri Jakku wrote:
>>>> On 3.5.2020 2.15, Heiner Kallweit wrote:
>>>>> On 03.05.2020 00:42, Lauri Jakku wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2.5.2020 20.56, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 1.5.2020 22.12, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>> On 19.4.2020 19.00, Heiner Kallweit wrote:
>>>>>>>>> On 19.04.2020 18:49, Lauri Jakku wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>>>>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without modifications --> network does not work
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified kernel (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy patched + r8169 mods -> devices show up ok, network works
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're presumable affected by a known BIOS bug.
>>>>>>>>>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at bugzilla.kernel.org.
>>>>>>>>>>>>>>>>>>>>>> In the first referenced tickets it's about the same mainboard (with earlier BIOS version).
>>>>>>>>>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize the network chip / PHY correctly, it reports
>>>>>>>>>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY driver being found.
>>>>>>>>>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and your problem should be gone.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now testing some mutex guard for phy state and try to use it as indicator
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> that attach has been done. One thing i've noticed is that driver needs to be reloaded to allow traffic (ie. ping works etc.)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> All that shouldn't be needed. Just check with which PHY ID the PHY comes up.
>>>>>>>>>>>>>>>>>>> And what do you mean with "it seems"? Is the option enabled or not?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I do have ROM's enabled, and it does not help with my issue.
>>>>>>>>>>>>>>>> Your BIOS is a beta version, downgrading to F7 may help. Then you have the same
>>>>>>>>>>>>>>>> mainboard + BIOS as the user who opened bug ticket 202275.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: MAC version: 23
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> .. after module unload & load cycle:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: MAC version: 23
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> it seem to be the case that the phy_id chances onetime, then stays the same. I'll do few shutdowns and see
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is there a pattern at all .. next i'm going to try how it behaves, if i read mac/phy versions twice on MAC version 23.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The BIOS downgrade: I'd like to solve this without downgrading BIOS. If I can't, then I'll do systemd-service that
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> reloads r8169 driver at boot, cause then network is just fine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What i've gathered samples now, there is three values for PHY ID:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo journalctl |grep "PHY ver"
>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I dont know are those hard coded or what, and are they device specific how much.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> i haven't coldbooted things up, that may be that something to check do they vary how per coldboot.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I check the ID, and revert all other changes, and check how it is working after adding the PHY id to list.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> What i've now learned: the patch + script + journald services -> Results working network, but it is still a workaround.
>>>>>>>>>>>>>
>>>>>>>>>>>> Following patch trusts the MAC version, another thing witch could help is to derive method to do 2dn pass of the probeing:
>>>>>>>>>>>>
>>>>>>>>>>>> if specific MAC version is found.
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>> index acd122a88d4a..62b37a1abc24 100644
>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>> @@ -5172,13 +5172,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>> - /* Most chip versions fail with the genphy driver.
>>>>>>>>>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>>>>>> - */
>>>>>>>>>>>> - dev_err(&pdev->dev, "Not known MAC version.\n");
>>>>>>>>>>>> - mdiobus_unregister(new_bus);
>>>>>>>>>>>> - return -EUNATCH;
>>>>>>>>>>>> + } else {
>>>>>>>>>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>>>>>>>>>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>>>>>>>>>>> +
>>>>>>>>>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>> + /* Most chip versions fail with the genphy driver.
>>>>>>>>>>>> + * Therefore ensure that the dedicated PHY driver is loaded.
>>>>>>>>>>>> + */
>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n", tp->phydev->phy_id);
>>>>>>>>>>>> + mdiobus_unregister(new_bus);
>>>>>>>>>>>> + return -EUNATCH;
>>>>>>>>>>>> + }
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>>>>>>>
>>>>>>>>>>> I just got bleeding edge 5.7.0-1 kernel compiled + firmware's updated.. and now up'n'running. There is one (WARN_ONCE) stack trace coming from driver, i think i tinker with it next, with above patch the network devices shows up and they can be configured.
>>>>>>>>>>>
>>>>>>>>>> I tought to ask first, before going to make new probe_type for errorneus hw (propetype + retry counter) to do re-probe if requested, N times. Or should the r8169_main.c return deferred probe on error on some MAC enums ? Which approach is design-wise sound ?
>>>>>>>>>>
>>>>>>>>>> I just tought that the DEFERRED probe may just do the trick i'm looking ways to implement the re-probeing... hmm. I try the deferred thing and check would that help.
>>>>>>>>>>
>>>>>>>>> Playing with options to work around the issue is of course a great way to
>>>>>>>>> learn about the kernel. However it's questionable whether a workaround in
>>>>>>>>> the driver is acceptable for dealing with the broken BIOS of exactly one
>>>>>>>>>> 10 yrs old board (for which even a userspace workaround exists).
>>>>>>>> problem recognized: libphy-module get's unloaded for some reason before r8169 driver loads -> missing lowlevel functionality -> not working driver. This only occurs at 1st load of module.. seeking solution.
>>>>>>>>
>>>>>>>>
>>>>>>>> There is [last unloaded: libphy] entries in log BEFORE r8169 is probed first time.
>>>>>>>>
>>>>>>>>
>>>>>>>> Any clue what is responsible for unloading to occur ?
>>>>>>>>
>>>>>>>>
>>>>>>> Right now I'm debugging what is the reason, behind that the module starts to work properly only when
>>>>>>>
>>>>>>> unload & reload cycle is done.
>>>>>>>
>>>>>>>
>>>>>>> The libphy is listed as loaded, but the check for low level read/write function is not set -> r8169 modules rlt_open() fails.
>>>>>>>
>>>>>>> See here:
>>>>>>>
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: ------------[ cut here ]------------
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: read_page callback not available, PHY driver not loaded?
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: WARNING: CPU: 3 PID: 787 at drivers/net/phy/phy-core.c:750 phy_save_page+0xb1/0xe3 [libph
>>>>>>> y]
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Modules linked in: cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel b
>>>>>>> luetooth ecdh_generic rfkill ecc uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio videobuf2_v4l2 videobuf2_common snd_usbmidi_
>>>>>>> lib videodev snd_rawmidi snd_seq_device mc input_leds joydev mousedev squashfs loop amdgpu snd_hda_codec_realtek gpu_sched i2c_algo_bit
>>>>>>> ttm snd_hda_codec_generic drm_kms_helper edac_mce_amd ledtrig_audio cec rc_core kvm_amd drm ccp snd_hda_codec_hdmi agpgart rng_core kv
>>>>>>> m snd_hda_intel syscopyarea sysfillrect ppdev sysimgblt snd_intel_dspcfg fb_sys_fops snd_hda_codec snd_hda_core snd_hwdep irqbypass wmi
>>>>>>> _bmof snd_pcm snd_timer snd evdev pcspkr soundcore parport_pc parport sp5100_tco mac_hid i2c_piix4 k10temp acpi_cpufreq uinput crypto_u
>>>>>>> ser ip_tables x_tables hid_generic usbhid hid ohci_pci virtio_net net_failover failover firewire_ohci firewire_core crc_itu_t pata_atii
>>>>>>> xp ehci_pci ehci_hcd sr_mod cdrom ohci_hcd ata_generic pata_acpi pata_jmicron wmi floppy
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: r8169 realtek libphy
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: CPU: 3 PID: 787 Comm: NetworkManager Not tainted 5.7.0-1-raw #12
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Hardware name: Gigabyte Technology Co., Ltd. GA-MA790FXT-UD5P/GA-MA790FXT-UD5P, BIOS F8l 07/15/2010
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RIP: 0010:phy_save_page+0xb1/0xe3 [libphy]
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Code: c8 82 11 c0 e8 06 28 ff cc 85 db 74 47 48 8b 85 48 03 00 00 48 83 b8 68 01 00 00 00 75 10 48 c7 c7 e8 82 11 c0 e8 a9 dd f7 cc <0f> 0b eb 26 48 c7 c7 52 78 11 c0 e8 99 dd f7 cc 0f 0b 48 8b 85 48
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RSP: 0018:ffff962c408ef370 EFLAGS: 00010282
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RDX: 0000000000000001 RSI: 0000000000000092 RDI: 00000000ffffffff
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: RBP: ffff8b1af3eb8800 R08: 00000000000004b3 R09: 0000000000000004
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffa1
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R13: 0000000000000002 R14: 0000000000000002 R15: ffff8b1af3eb8800
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: FS: 00007f07be5d4d80(0000) GS:ffff8b1af7cc0000(0000) knlGS:0000000000000000
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CR2: 000055b83aecb008 CR3: 00000002246b0000 CR4: 00000000000006e0
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: Call Trace:
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: phy_select_page+0x53/0x7a [libphy]
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: phy_write_paged+0x5c/0xa0 [libphy]
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl8168d_1_hw_phy_config+0x9d/0x210 [r8169]
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl8169_init_phy+0x19/0x110 [r8169]
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: rtl_open+0x354/0x4d0 [r8169]
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_open+0xe0/0x170
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: __dev_change_flags+0x188/0x1e0
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: dev_change_flags+0x21/0x60
>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: do_setlink+0x78a/0xfd0
>>>>>>>
>>>>>>>
>>>>>>> Something does not setup/register properly at first the way it should.
>>>>>>>
>>>>>>>
>>>>>> I think i solved it: realtek (the phy driver) was missing device entry for the PHY ID reported by the NIC to match -> read_page and write_page function pointers should now be set. The generic PHY does not fill
>>>>>>
>>>>>> the driver's functionality to read or write pages. It happens to be so that the drivers for |RTL8211B Gigabit Ethernet seems to work just fine for my NIC's.
>>>>> The analysis is wrong. The incorrect PHY ID is not root cause of the
>>>>> problem, it's caused by a BIOS bug. It's not a valid PHY ID. If you want
>>>>> to do something, then you could try to inject a PHY soft reset before
>>>>> the MII bus is registered. This should be board-specific, e.g. using
>>>>> dmi_check_system().
>>>> Ok, i'll try that approach, thanks for the tip. Hmm, I'll do similar function mapping what the HW init/config function does determine
>>>>
>>>> function to use.
>>>>
>>>>
>>>> I'll get back to you when I got something new developed.
>>>>
>>> Oujeah, now it works OK.. the soft reset was all it needed.
>>>
>>>
>>> Here's the patch:
>>>
>>> From 06c5deacf3ca9f9258431756a41ff0ba1792f1f7 Mon Sep 17 00:00:00 2001
>>> From: Lauri Jakku<lja@iki.fi>
>>> Date: Thu, 16 Apr 2020 00:38:51 +0300
>>> Subject: [PATCH] NET: r8169 driver identifying improvement.
>>>
>>> Trust device MAC enum + r8169d NIC soft reset
>>> before configuration.
>>>
>>> This commit adds enumeration check and allows
>>> driver to be slow to attach.
>>>
>>> Signed-off-by: Lauri Jakku<lja@iki.fi>
>>> ---
>>> drivers/net/ethernet/realtek/r8169_main.c | 24 +++--
>>> .../net/ethernet/realtek/r8169_phy_config.c | 80 ++++++++++++++++
>>> drivers/net/phy/phy-core.c | 91 ++++++++++++++++++-
>>> 3 files changed, 182 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>> index bf5bf05970a2..a85764f6e448 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>> @@ -640,7 +640,6 @@ MODULE_AUTHOR("Realtek and the Linux r8169 crew<netdev@vger.kernel.org>");
>>> MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
>>> module_param_named(debug, debug.msg_enable, int, 0);
>>> MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
>>> -MODULE_SOFTDEP("pre: realtek");
>>> MODULE_LICENSE("GPL");
>>> MODULE_FIRMWARE(FIRMWARE_8168D_1);
>>> MODULE_FIRMWARE(FIRMWARE_8168D_2);
>>> @@ -5172,13 +5171,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>> if (!tp->phydev) {
>>> mdiobus_unregister(new_bus);
>>> return -ENODEV;
>>> - } else if (!tp->phydev->drv) {
>>> - /* Most chip versions fail with the genphy driver.
>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>> - */
>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>>> - mdiobus_unregister(new_bus);
>>> - return -EUNATCH;
>>> + } else {
>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>> +
>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>> + /* Most chip versions fail with the genphy driver.
>>> + * Therefore ensure that the dedicated PHY driver is loaded.
>>> + */
>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n");
>>> + mdiobus_unregister(new_bus);
>>> + return -EUNATCH;
>>> + }
>>> }
>>>
>>> /* PHY will be woken up in rtl_open() */
>>> @@ -5513,6 +5517,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> rtl_chip_infos[chipset].name, dev->dev_addr, xid,
>>> pci_irq_vector(pdev, 0));
>>>
>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>> +
>>> if (jumbo_max)
>>> netif_info(tp, probe, dev,
>>> "jumbo features [frames: %d bytes, tx checksumming: %s]\n", @@ -5532,6 +5539,7 @@ static int rtl_init_one(struct pci_dev
>>> *pdev, const struct pci_device_id *ent) return rc; } + static
>>> struct pci_driver rtl8169_pci_driver = { .name =
>>> MODULENAME, .id_table = rtl8169_pci_tbl, diff --git
>>> a/drivers/net/ethernet/realtek/r8169_phy_config.c
>>> b/drivers/net/ethernet/realtek/r8169_phy_config.c index
>>> b73f7d023e99..73d604c7a8a8 100644 ---
>>> a/drivers/net/ethernet/realtek/r8169_phy_config.c +++
>>> b/drivers/net/ethernet/realtek/r8169_phy_config.c @@ -1243,6
>>> +1243,84 @@ static void rtl8125_2_hw_phy_config(struct
>>> rtl8169_private *tp, rtl8125_config_eee_phy(phydev); } +
>>> +static void rtl8168d_hw_phy_pre_config_actions(struct
>>> rtl8169_private *tp, + struct phy_device
>>> *phydev) +{ + /* Reset the PHY before configuration. There is
>>> BIOS bug that gives + * random PHY ID when device is not soft
>>> resetted first. --lja + */ + genphy_soft_reset(phydev); +} +
>>> + + +void r8169_hw_phy_pre_config_actions(struct rtl8169_private
>>> *tp, struct phy_device *phydev, + enum
>>> mac_version ver) +{ + static const rtl_phy_cfg_fct
>>> phy_pre_config_actions[] = { + /* PCI devices. */ +
>>> [RTL_GIGA_MAC_VER_02] = NULL, + [RTL_GIGA_MAC_VER_03] = NULL,
>>> + [RTL_GIGA_MAC_VER_04] = NULL, +
>>> [RTL_GIGA_MAC_VER_05] = NULL, + [RTL_GIGA_MAC_VER_06] = NULL,
>>> + /* PCI-E devices. */ + [RTL_GIGA_MAC_VER_07] = NULL,
>>> + [RTL_GIGA_MAC_VER_08] = NULL, +
>>> [RTL_GIGA_MAC_VER_09] = NULL, + [RTL_GIGA_MAC_VER_10] = NULL,
>>> + [RTL_GIGA_MAC_VER_11] = NULL, +
>>> [RTL_GIGA_MAC_VER_12] = NULL, + [RTL_GIGA_MAC_VER_13] = NULL,
>>> + [RTL_GIGA_MAC_VER_14] = NULL, +
>>> [RTL_GIGA_MAC_VER_15] = NULL, + [RTL_GIGA_MAC_VER_16] = NULL,
>>> + [RTL_GIGA_MAC_VER_17] = NULL, +
>>> [RTL_GIGA_MAC_VER_18] = NULL, + [RTL_GIGA_MAC_VER_19] = NULL,
>>> + [RTL_GIGA_MAC_VER_20] = NULL, +
>>> [RTL_GIGA_MAC_VER_21] = NULL, + [RTL_GIGA_MAC_VER_22] = NULL,
>>> + [RTL_GIGA_MAC_VER_23] = NULL, +
>>> [RTL_GIGA_MAC_VER_24] = NULL, + [RTL_GIGA_MAC_VER_25] =
>>> rtl8168d_hw_phy_pre_config_actions, + [RTL_GIGA_MAC_VER_26] =
>>> rtl8168d_hw_phy_pre_config_actions, + [RTL_GIGA_MAC_VER_27] =
>>> rtl8168d_hw_phy_pre_config_actions, + [RTL_GIGA_MAC_VER_28] =
>>> rtl8168d_hw_phy_pre_config_actions, + [RTL_GIGA_MAC_VER_29] =
>>> NULL, + [RTL_GIGA_MAC_VER_30] = NULL, +
>>> [RTL_GIGA_MAC_VER_31] = NULL, + [RTL_GIGA_MAC_VER_32] = NULL,
>>> + [RTL_GIGA_MAC_VER_33] = NULL, +
>>> [RTL_GIGA_MAC_VER_34] = NULL, + [RTL_GIGA_MAC_VER_35] = NULL,
>>> + [RTL_GIGA_MAC_VER_36] = NULL, +
>>> [RTL_GIGA_MAC_VER_37] = NULL, + [RTL_GIGA_MAC_VER_38] = NULL,
>>> + [RTL_GIGA_MAC_VER_39] = NULL, +
>>> [RTL_GIGA_MAC_VER_40] = NULL, + [RTL_GIGA_MAC_VER_41] = NULL,
>>> + [RTL_GIGA_MAC_VER_42] = NULL, +
>>> [RTL_GIGA_MAC_VER_43] = NULL, + [RTL_GIGA_MAC_VER_44] = NULL,
>>> + [RTL_GIGA_MAC_VER_45] = NULL, +
>>> [RTL_GIGA_MAC_VER_46] = NULL, + [RTL_GIGA_MAC_VER_47] = NULL,
>>> + [RTL_GIGA_MAC_VER_48] = NULL, +
>>> [RTL_GIGA_MAC_VER_49] = NULL, + [RTL_GIGA_MAC_VER_50] = NULL,
>>> + [RTL_GIGA_MAC_VER_51] = NULL, +
>>> [RTL_GIGA_MAC_VER_52] = NULL, + [RTL_GIGA_MAC_VER_60] = NULL,
>>> + [RTL_GIGA_MAC_VER_61] = NULL, + }; + + if
>>> (phy_pre_config_actions[ver]) +
>>> phy_pre_config_actions[ver](tp, phydev); +} + + void
>>> r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device
>>> *phydev, enum mac_version ver) { @@ -1303,6 +1381,8
>>> @@ void r8169_hw_phy_config(struct rtl8169_private *tp, struct
>>> phy_device *phydev, [RTL_GIGA_MAC_VER_60] =
>>> rtl8125_1_hw_phy_config, [RTL_GIGA_MAC_VER_61] =
>>> rtl8125_2_hw_phy_config, }; + +
>>> r8169_hw_phy_pre_config_actions(tp, phydev); if
>>> (phy_configs[ver]) phy_configs[ver](tp, phydev); diff --git
>>> a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c index
>>> 66b8c61ca74c..b170185a1ed1 100644 --- a/drivers/net/phy/phy-core.c
>>> +++ b/drivers/net/phy/phy-core.c @@ -151,6 +151,25 @@ static const
>>> struct phy_setting settings[] = { }; #undef PHY_SETTING +#ifdef
>>> DEBUG +#define R8169_ATTACHED_PRINTK \ + printk("Phy is attached check %s @ %d: %d\n", \
>>> + __FUNC__, __LINE__, is_attached_check);
>>> +
>>> +#else
>>> +#define R8169_ATTACHED_PRINTK
>>> +#endif
>>> +
>>> +#define PHY_NOT_ATTACHED_CHECK \
>>> + { \
>>> + void *attached_dev_ptr = (phydev) ? phydev->attached_dev : NULL; \
>>> + int is_attached_check = (attached_dev_ptr != NULL) && \
>>> + ((phydev) && (phydev->state >= PHY_READY)); \
>>> + R8169_ATTACHED_PRINTK \
>>> + if (! is_attached_check ) return -EOPNOTSUPP; \
>>> + };
>>> +
>>> +
>>> /**
>>> * phy_lookup_setting - lookup a PHY setting
>>> * @speed: speed to match
>>> @@ -457,6 +476,9 @@ int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> phy_lock_mdio_bus(phydev);
>>> ret = __phy_read_mmd(phydev, devad, regnum);
>>> phy_unlock_mdio_bus(phydev);
>>> @@ -479,6 +501,9 @@ int __phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> if (regnum > (u16)~0 || devad > 32)
>>> return -EINVAL;
>>>
>>> @@ -518,6 +543,9 @@ int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> phy_lock_mdio_bus(phydev);
>>> ret = __phy_write_mmd(phydev, devad, regnum, val);
>>> phy_unlock_mdio_bus(phydev);
>>> @@ -543,6 +571,10 @@ int phy_modify_changed(struct phy_device *phydev, u32 regnum, u16 mask, u16 set)
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> +
>>> phy_lock_mdio_bus(phydev);
>>> ret = __phy_modify_changed(phydev, regnum, mask, set);
>>> phy_unlock_mdio_bus(phydev);
>>> @@ -587,6 +619,9 @@ int phy_modify(struct phy_device *phydev, u32 regnum, u16 mask, u16 set)
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> phy_lock_mdio_bus(phydev);
>>> ret = __phy_modify(phydev, regnum, mask, set);
>>> phy_unlock_mdio_bus(phydev);
>>> @@ -613,6 +648,9 @@ int __phy_modify_mmd_changed(struct phy_device *phydev, int devad, u32 regnum,
>>> {
>>> int new, ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> ret = __phy_read_mmd(phydev, devad, regnum);
>>> if (ret < 0)
>>> return ret;
>>> @@ -646,6 +684,10 @@ int phy_modify_mmd_changed(struct phy_device *phydev, int devad, u32 regnum,
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> +
>>> phy_lock_mdio_bus(phydev);
>>> ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask, set);
>>> phy_unlock_mdio_bus(phydev);
>>> @@ -671,6 +713,9 @@ int __phy_modify_mmd(struct phy_device *phydev, int devad, u32 regnum,
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask, set);
>>>
>>> return ret < 0 ? ret : 0;
>>> @@ -694,6 +739,9 @@ int phy_modify_mmd(struct phy_device *phydev, int devad, u32 regnum,
>>> {
>>> int ret;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> phy_lock_mdio_bus(phydev);
>>> ret = __phy_modify_mmd(phydev, devad, regnum, mask, set);
>>> phy_unlock_mdio_bus(phydev);
>>> @@ -704,7 +752,11 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>
>>> static int __phy_read_page(struct phy_device *phydev)
>>> {
>>> - if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>> +
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> + if (WARN(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
>>> return -EOPNOTSUPP;
>>>
>>> return phydev->drv->read_page(phydev);
>>> @@ -712,12 +764,16 @@ static int __phy_read_page(struct phy_device *phydev)
>>>
>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>> {
>>> - if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> + if (WARN(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
>>> return -EOPNOTSUPP;
>>>
>>> return phydev->drv->write_page(phydev, page);
>>> }
>>>
>>> +
>>> /**
>>> * phy_save_page() - take the bus lock and save the current page
>>> * @phydev: a pointer to a &struct phy_device
>>> @@ -728,7 +784,11 @@ static int __phy_write_page(struct phy_device *phydev, int page)
>>> */
>>> int phy_save_page(struct phy_device *phydev)
>>> {
>>> - phy_lock_mdio_bus(phydev);
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> +
>>> + phy_lock_mdio_bus(phydev);
>>> return __phy_read_page(phydev);
>>> }
>>> EXPORT_SYMBOL_GPL(phy_save_page);
>>> @@ -748,7 +808,10 @@ int phy_select_page(struct phy_device *phydev, int page)
>>> {
>>> int ret, oldpage;
>>>
>>> - oldpage = ret = phy_save_page(phydev);
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> + oldpage = ret = phy_save_page(phydev);
>>> if (ret < 0)
>>> return ret;
>>>
>>> @@ -782,6 +845,9 @@ int phy_restore_page(struct phy_device *phydev, int oldpage, int ret)
>>> {
>>> int r;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> if (oldpage >= 0) {
>>> r = __phy_write_page(phydev, oldpage);
>>>
>>> @@ -812,6 +878,9 @@ EXPORT_SYMBOL_GPL(phy_restore_page);
>>> int phy_read_paged(struct phy_device *phydev, int page, u32 regnum)
>>> {
>>> int ret = 0, oldpage;
>>> +
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>>
>>> oldpage = phy_select_page(phydev, page);
>>> if (oldpage >= 0)
>>> @@ -834,6 +903,10 @@ int phy_write_paged(struct phy_device *phydev, int page, u32 regnum, u16 val)
>>> {
>>> int ret = 0, oldpage;
>>>
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> +
>>> oldpage = phy_select_page(phydev, page);
>>> if (oldpage >= 0)
>>> ret = __phy_write(phydev, regnum, val);
>>> @@ -856,6 +929,9 @@ int phy_modify_paged_changed(struct phy_device *phydev, int page, u32 regnum,
>>> u16 mask, u16 set)
>>> {
>>> int ret = 0, oldpage;
>>> +
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>>
>>> oldpage = phy_select_page(phydev, page);
>>> if (oldpage >= 0)
>>> @@ -878,7 +954,12 @@ EXPORT_SYMBOL(phy_modify_paged_changed);
>>> int phy_modify_paged(struct phy_device *phydev, int page, u32 regnum,
>>> u16 mask, u16 set)
>>> {
>>> - int ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
>>> + int ret = -1;
>>> +
>>> + /* If not attached, do nothing. */
>>> + PHY_NOT_ATTACHED_CHECK;
>>> +
>>> + ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
>>>
>>> return ret < 0 ? ret : 0;
>>> }
>> here is the polished patch:
>>
>> From 6dd6f2813c543dc728efb8dca796bbbe870bd031 Mon Sep 17 00:00:00 2001
>> From: Lauri Jakku<lja@iki.fi>
>> Date: Thu, 16 Apr 2020 00:38:51 +0300
>> Subject: [PATCH] NET: r8169 driver identifying improvement.
>>
>> Trust device MAC enum + r8169d NIC soft reset
>> before configuration.
>>
>> This commit adds enumeration check and allows
>> driver to be slow to attach.
>>
>> Signed-off-by: Lauri Jakku<lja@iki.fi>
>> ---
>> drivers/net/ethernet/realtek/r8169_main.c | 21 +++--
>> .../net/ethernet/realtek/r8169_phy_config.c | 80 +++++++++++++++++++
>> 2 files changed, 93 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index bf5bf05970a2..6828e755a460 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -640,7 +640,6 @@ MODULE_AUTHOR("Realtek and the Linux r8169 crew<netdev@vger.kernel.org>");
>> MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
>> module_param_named(debug, debug.msg_enable, int, 0);
>> MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
>> -MODULE_SOFTDEP("pre: realtek");
>> MODULE_LICENSE("GPL");
>> MODULE_FIRMWARE(FIRMWARE_8168D_1);
>> MODULE_FIRMWARE(FIRMWARE_8168D_2);
>> @@ -5172,13 +5171,18 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> if (!tp->phydev) {
>> mdiobus_unregister(new_bus);
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is loaded.
>> - */
>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
>> - mdiobus_unregister(new_bus);
>> - return -EUNATCH;
>> + } else {
>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>> +
>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>> + /* Most chip versions fail with the genphy driver.
>> + * Therefore ensure that the dedicated PHY driver is loaded.
>> + */
>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n");
>> + mdiobus_unregister(new_bus);
>> + return -EUNATCH;
>> + }
>> }
>>
>> /* PHY will be woken up in rtl_open() */
>> @@ -5532,6 +5536,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> return rc;
>> }
>>
>> +
>> static struct pci_driver rtl8169_pci_driver = {
>> .name = MODULENAME,
>> .id_table = rtl8169_pci_tbl,
>> diff --git a/drivers/net/ethernet/realtek/r8169_phy_config.c b/drivers/net/ethernet/realtek/r8169_phy_config.c
>> index b73f7d023e99..f13f68b79a92 100644
>> --- a/drivers/net/ethernet/realtek/r8169_phy_config.c
>> +++ b/drivers/net/ethernet/realtek/r8169_phy_config.c
>> @@ -1243,6 +1243,84 @@ static void rtl8125_2_hw_phy_config(struct rtl8169_private *tp,
>> rtl8125_config_eee_phy(phydev);
>> }
>>
>> +
>> +static void rtl8168d_hw_phy_pre_config_actions(struct rtl8169_private *tp,
>> + struct phy_device *phydev)
>> +{
>> + /* Reset the PHY before configuration. There is BIOS bug that gives
>> + * random PHY ID when device is not soft resetted first. --lja
>> + */
>> + genphy_soft_reset(phydev);
>> +}
>> +
>> +
>> +
>> +void r8169_hw_phy_pre_config_actions(struct rtl8169_private *tp, struct phy_device *phydev,
>> + enum mac_version ver)
>> +{
>> + static const rtl_phy_cfg_fct phy_pre_config_actions[] = {
>> + /* PCI devices. */
>> + [RTL_GIGA_MAC_VER_02] = NULL,
>> + [RTL_GIGA_MAC_VER_03] = NULL,
>> + [RTL_GIGA_MAC_VER_04] = NULL,
>> + [RTL_GIGA_MAC_VER_05] = NULL,
>> + [RTL_GIGA_MAC_VER_06] = NULL,
>> + /* PCI-E devices. */
>> + [RTL_GIGA_MAC_VER_07] = NULL,
>> + [RTL_GIGA_MAC_VER_08] = NULL,
>> + [RTL_GIGA_MAC_VER_09] = NULL,
>> + [RTL_GIGA_MAC_VER_10] = NULL,
>> + [RTL_GIGA_MAC_VER_11] = NULL,
>> + [RTL_GIGA_MAC_VER_12] = NULL,
>> + [RTL_GIGA_MAC_VER_13] = NULL,
>> + [RTL_GIGA_MAC_VER_14] = NULL,
>> + [RTL_GIGA_MAC_VER_15] = NULL,
>> + [RTL_GIGA_MAC_VER_16] = NULL,
>> + [RTL_GIGA_MAC_VER_17] = NULL,
>> + [RTL_GIGA_MAC_VER_18] = NULL,
>> + [RTL_GIGA_MAC_VER_19] = NULL,
>> + [RTL_GIGA_MAC_VER_20] = NULL,
>> + [RTL_GIGA_MAC_VER_21] = NULL,
>> + [RTL_GIGA_MAC_VER_22] = NULL,
>> + [RTL_GIGA_MAC_VER_23] = NULL,
>> + [RTL_GIGA_MAC_VER_24] = NULL,
>> + [RTL_GIGA_MAC_VER_25] = rtl8168d_hw_phy_pre_config_actions,
>> + [RTL_GIGA_MAC_VER_26] = rtl8168d_hw_phy_pre_config_actions,
>> + [RTL_GIGA_MAC_VER_27] = rtl8168d_hw_phy_pre_config_actions,
>> + [RTL_GIGA_MAC_VER_28] = rtl8168d_hw_phy_pre_config_actions,
>> + [RTL_GIGA_MAC_VER_29] = NULL,
>> + [RTL_GIGA_MAC_VER_30] = NULL,
>> + [RTL_GIGA_MAC_VER_31] = NULL,
>> + [RTL_GIGA_MAC_VER_32] = NULL,
>> + [RTL_GIGA_MAC_VER_33] = NULL,
>> + [RTL_GIGA_MAC_VER_34] = NULL,
>> + [RTL_GIGA_MAC_VER_35] = NULL,
>> + [RTL_GIGA_MAC_VER_36] = NULL,
>> + [RTL_GIGA_MAC_VER_37] = NULL,
>> + [RTL_GIGA_MAC_VER_38] = NULL,
>> + [RTL_GIGA_MAC_VER_39] = NULL,
>> + [RTL_GIGA_MAC_VER_40] = NULL,
>> + [RTL_GIGA_MAC_VER_41] = NULL,
>> + [RTL_GIGA_MAC_VER_42] = NULL,
>> + [RTL_GIGA_MAC_VER_43] = NULL,
>> + [RTL_GIGA_MAC_VER_44] = NULL,
>> + [RTL_GIGA_MAC_VER_45] = NULL,
>> + [RTL_GIGA_MAC_VER_46] = NULL,
>> + [RTL_GIGA_MAC_VER_47] = NULL,
>> + [RTL_GIGA_MAC_VER_48] = NULL,
>> + [RTL_GIGA_MAC_VER_49] = NULL,
>> + [RTL_GIGA_MAC_VER_50] = NULL,
>> + [RTL_GIGA_MAC_VER_51] = NULL,
>> + [RTL_GIGA_MAC_VER_52] = NULL,
>> + [RTL_GIGA_MAC_VER_60] = NULL,
>> + [RTL_GIGA_MAC_VER_61] = NULL,
>> + };
>> +
>> + if (phy_pre_config_actions[ver])
>> + phy_pre_config_actions[ver](tp, phydev);
>> +}
>> +
>> +
>> void r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device *phydev,
>> enum mac_version ver)
>> {
>> @@ -1304,6 +1382,8 @@ void r8169_hw_phy_config(struct rtl8169_private *tp, struct phy_device *phydev,
>> [RTL_GIGA_MAC_VER_61] = rtl8125_2_hw_phy_config,
>> };
>>
>> + r8169_hw_phy_pre_config_actions(tp, phydev, ver);
>> +
>> if (phy_configs[ver])
>> phy_configs[ver](tp, phydev);
>> }
> The PHY ID is checked from devm_mdiobus_register(), you're way too late
> with the soft reset. Also I said if a quirk is needed then it has to be
> board-specific. This is not a problem of the chip version in general.
> What you do in r8169_mdio_register() is simply wrong.
> Last but not least you mix 100 different things in one patch.
Hmm, now i'm suspecting that if(!tp->phydev->drv) is always true with my
HW, the version i've made to check HW existance via MAC is ok..
Phy registering is not done properly, where the drv it gets filled. I do
have all three modules loaded (i've made hard depepency chain via
exported symbols so r8169 has link to Realtek-phy that has link to
libphy.) Everything seems ok, all get's loaded ok, but the IF case is
always true, but mac is read from HW ok.
So, any suggestions how to make r8169 to register with PHY layer?
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-05-03 13:54 ` Lauri Jakku
@ 2020-05-19 5:15 ` Lauri Jakku
0 siblings, 0 replies; 57+ messages in thread
From: Lauri Jakku @ 2020-05-19 5:15 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
[-- Attachment #1: Type: text/plain, Size: 46135 bytes --]
Hi,
On 3.5.2020 16.54, Lauri Jakku wrote:
> Hi,
>
> On 3.5.2020 11.33, Heiner Kallweit wrote:
>> On 03.05.2020 04:28, Lauri Jakku wrote:
>>> Hi,
>>>
>>> On 3.5.2020 4.34, Lauri Jakku wrote:
>>>> Hi,
>>>>
>>>>
>>>> On 3.5.2020 3.11, Lauri Jakku wrote:
>>>>> On 3.5.2020 2.15, Heiner Kallweit wrote:
>>>>>> On 03.05.2020 00:42, Lauri Jakku wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2.5.2020 20.56, Lauri Jakku wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 1.5.2020 22.12, Lauri Jakku wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 19.4.2020 19.00, Heiner Kallweit wrote:
>>>>>>>>>> On 19.04.2020 18:49, Lauri Jakku wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 19.4.2020 18.09, Lauri Jakku wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On 18.4.2020 21.46, Lauri Jakku wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 18.4.2020 14.06, Lauri Jakku wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 17.4.2020 10.30, Lauri Jakku wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 17.4.2020 9.23, Lauri Jakku wrote:
>>>>>>>>>>>>>>>> On 16.4.2020 23.50, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>> On 16.04.2020 22:38, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 16.4.2020 23.10, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>> On 16.4.2020 23.02, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>>>>> On 16.04.2020 21:58, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 16.4.2020 21.37, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 16.4.2020 21.26, Heiner Kallweit wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 16.04.2020 13:30, Lauri Jakku wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO: stock manjaro kernel, without
>>>>>>>>>>>>>>>>>>>>>>>> modifications --> network does not work
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-lja: No attach check, modified
>>>>>>>>>>>>>>>>>>>>>>>> kernel (r8169 mods only) --> network does not work
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 5.6.3-2-MANJARO-with-the-r8169-patch: phy
>>>>>>>>>>>>>>>>>>>>>>>> patched + r8169 mods -> devices show up ok,
>>>>>>>>>>>>>>>>>>>>>>>> network works
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> All different initcpio's have realtek.ko in them.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks for the logs. Based on the logs you're
>>>>>>>>>>>>>>>>>>>>>>> presumable affected by a known BIOS bug.
>>>>>>>>>>>>>>>>>>>>>>> Check bug tickets 202275 and 207203 at
>>>>>>>>>>>>>>>>>>>>>>> bugzilla.kernel.org.
>>>>>>>>>>>>>>>>>>>>>>> In the first referenced tickets it's about the
>>>>>>>>>>>>>>>>>>>>>>> same mainboard (with earlier BIOS version).
>>>>>>>>>>>>>>>>>>>>>>> BIOS on this mainboard seems to not initialize
>>>>>>>>>>>>>>>>>>>>>>> the network chip / PHY correctly, it reports
>>>>>>>>>>>>>>>>>>>>>>> a random number as PHY ID, resulting in no PHY
>>>>>>>>>>>>>>>>>>>>>>> driver being found.
>>>>>>>>>>>>>>>>>>>>>>> Enable "Onboard LAN Boot ROM" in the BIOS, and
>>>>>>>>>>>>>>>>>>>>>>> your problem should be gone.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> OK, I try that, thank you :)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It seems that i DO have the ROM's enabled, i'm now
>>>>>>>>>>>>>>>>>>>>> testing some mutex guard for phy state and try to
>>>>>>>>>>>>>>>>>>>>> use it as indicator
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> that attach has been done. One thing i've noticed
>>>>>>>>>>>>>>>>>>>>> is that driver needs to be reloaded to allow
>>>>>>>>>>>>>>>>>>>>> traffic (ie. ping works etc.)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> All that shouldn't be needed. Just check with which
>>>>>>>>>>>>>>>>>>>> PHY ID the PHY comes up.
>>>>>>>>>>>>>>>>>>>> And what do you mean with "it seems"? Is the option
>>>>>>>>>>>>>>>>>>>> enabled or not?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I do have ROM's enabled, and it does not help with
>>>>>>>>>>>>>>>>>>> my issue.
>>>>>>>>>>>>>>>>> Your BIOS is a beta version, downgrading to F7 may
>>>>>>>>>>>>>>>>> help. Then you have the same
>>>>>>>>>>>>>>>>> mainboard + BIOS as the user who opened bug ticket
>>>>>>>>>>>>>>>>> 202275.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>>> 0000:03:00.0: MAC version: 23
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ....
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>>> 0000:02:00.0: MAC version: 23
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> .. after module unload & load cycle:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>>> 0000:02:00.0: MAC version: 23
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> it seem to be the case that the phy_id chances onetime,
>>>>>>>>>>>>>>>> then stays the same. I'll do few shutdowns and see
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> is there a pattern at all .. next i'm going to try how
>>>>>>>>>>>>>>>> it behaves, if i read mac/phy versions twice on MAC
>>>>>>>>>>>>>>>> version 23.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The BIOS downgrade: I'd like to solve this without
>>>>>>>>>>>>>>>> downgrading BIOS. If I can't, then I'll do
>>>>>>>>>>>>>>>> systemd-service that
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> reloads r8169 driver at boot, cause then network is
>>>>>>>>>>>>>>>> just fine.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What i've gathered samples now, there is three values
>>>>>>>>>>>>>>> for PHY ID:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [sillyme@MinistryOfSillyWalk KernelStuff]$ sudo
>>>>>>>>>>>>>>> journalctl |grep "PHY ver"
>>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>>>> huhti 17 09:01:49 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc2077002
>>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>> huhti 17 09:03:29 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>> huhti 17 09:17:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>>> huhti 17 09:24:53 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>> huhti 17 09:27:59 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>>> huhti 17 10:08:42 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>> huhti 17 10:12:07 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>>> huhti 17 10:20:35 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:03:00.0: PHY version: 0xc1071002
>>>>>>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:02:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>> huhti 17 10:23:46 MinistryOfSillyWalk kernel: r8169
>>>>>>>>>>>>>>> 0000:03:00.0: PHY version: 0x1cc912
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I dont know are those hard coded or what, and are they
>>>>>>>>>>>>>>> device specific how much.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> i haven't coldbooted things up, that may be that
>>>>>>>>>>>>>>> something to check do they vary how per coldboot.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I check the ID, and revert all other changes, and
>>>>>>>>>>>>>>>>>> check how it is working after adding the PHY id to list.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What i've now learned: the patch + script + journald
>>>>>>>>>>>>>> services -> Results working network, but it is still a
>>>>>>>>>>>>>> workaround.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Following patch trusts the MAC version, another thing
>>>>>>>>>>>>> witch could help is to derive method to do 2dn pass of the
>>>>>>>>>>>>> probeing:
>>>>>>>>>>>>>
>>>>>>>>>>>>> if specific MAC version is found.
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>> index acd122a88d4a..62b37a1abc24 100644
>>>>>>>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>>>>>>>> @@ -5172,13 +5172,18 @@ static int
>>>>>>>>>>>>> r8169_mdio_register(struct rtl8169_private *tp)
>>>>>>>>>>>>> if (!tp->phydev) {
>>>>>>>>>>>>> mdiobus_unregister(new_bus);
>>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>>> - } else if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>>> - /* Most chip versions fail with the genphy
>>>>>>>>>>>>> driver.
>>>>>>>>>>>>> - * Therefore ensure that the dedicated PHY
>>>>>>>>>>>>> driver is loaded.
>>>>>>>>>>>>> - */
>>>>>>>>>>>>> - dev_err(&pdev->dev, "Not known MAC
>>>>>>>>>>>>> version.\n");
>>>>>>>>>>>>> - mdiobus_unregister(new_bus);
>>>>>>>>>>>>> - return -EUNATCH;
>>>>>>>>>>>>> + } else {
>>>>>>>>>>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n",
>>>>>>>>>>>>> tp->phydev->phy_id);
>>>>>>>>>>>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>>>>>>>>>>> + /* Most chip versions fail with
>>>>>>>>>>>>> the genphy driver.
>>>>>>>>>>>>> + * Therefore ensure that the
>>>>>>>>>>>>> dedicated PHY driver is loaded.
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n",
>>>>>>>>>>>>> tp->phydev->phy_id);
>>>>>>>>>>>>> + mdiobus_unregister(new_bus);
>>>>>>>>>>>>> + return -EUNATCH;
>>>>>>>>>>>>> + }
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> /* PHY will be woken up in rtl_open() */
>>>>>>>>>>>>>
>>>>>>>>>>>> I just got bleeding edge 5.7.0-1 kernel compiled +
>>>>>>>>>>>> firmware's updated.. and now up'n'running. There is one
>>>>>>>>>>>> (WARN_ONCE) stack trace coming from driver, i think i
>>>>>>>>>>>> tinker with it next, with above patch the network devices
>>>>>>>>>>>> shows up and they can be configured.
>>>>>>>>>>>>
>>>>>>>>>>> I tought to ask first, before going to make new probe_type
>>>>>>>>>>> for errorneus hw (propetype + retry counter) to do re-probe
>>>>>>>>>>> if requested, N times. Or should the r8169_main.c return
>>>>>>>>>>> deferred probe on error on some MAC enums ? Which approach
>>>>>>>>>>> is design-wise sound ?
>>>>>>>>>>>
>>>>>>>>>>> I just tought that the DEFERRED probe may just do the trick
>>>>>>>>>>> i'm looking ways to implement the re-probeing... hmm. I try
>>>>>>>>>>> the deferred thing and check would that help.
>>>>>>>>>>>
>>>>>>>>>> Playing with options to work around the issue is of course a
>>>>>>>>>> great way to
>>>>>>>>>> learn about the kernel. However it's questionable whether a
>>>>>>>>>> workaround in
>>>>>>>>>> the driver is acceptable for dealing with the broken BIOS of
>>>>>>>>>> exactly one
>>>>>>>>>>> 10 yrs old board (for which even a userspace workaround
>>>>>>>>>>> exists).
>>>>>>>>> problem recognized: libphy-module get's unloaded for some
>>>>>>>>> reason before r8169 driver loads -> missing lowlevel
>>>>>>>>> functionality -> not working driver. This only occurs at 1st
>>>>>>>>> load of module.. seeking solution.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There is [last unloaded: libphy] entries in log BEFORE r8169
>>>>>>>>> is probed first time.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Any clue what is responsible for unloading to occur ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Right now I'm debugging what is the reason, behind that the
>>>>>>>> module starts to work properly only when
>>>>>>>>
>>>>>>>> unload & reload cycle is done.
>>>>>>>>
>>>>>>>>
>>>>>>>> The libphy is listed as loaded, but the check for low level
>>>>>>>> read/write function is not set -> r8169 modules rlt_open() fails.
>>>>>>>>
>>>>>>>> See here:
>>>>>>>>
>>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: ------------[ cut
>>>>>>>> here ]------------
>>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: read_page
>>>>>>>> callback not available, PHY driver not loaded?
>>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: WARNING: CPU: 3
>>>>>>>> PID: 787 at drivers/net/phy/phy-core.c:750
>>>>>>>> phy_save_page+0xb1/0xe3 [libph
>>>>>>>> y]
>>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Modules linked
>>>>>>>> in: cmac algif_hash algif_skcipher af_alg bnep btusb btrtl
>>>>>>>> btbcm btintel b
>>>>>>>> luetooth ecdh_generic rfkill ecc uvcvideo videobuf2_vmalloc
>>>>>>>> videobuf2_memops snd_usb_audio videobuf2_v4l2 videobuf2_common
>>>>>>>> snd_usbmidi_
>>>>>>>> lib videodev snd_rawmidi snd_seq_device mc input_leds joydev
>>>>>>>> mousedev squashfs loop amdgpu snd_hda_codec_realtek gpu_sched
>>>>>>>> i2c_algo_bit
>>>>>>>> ttm snd_hda_codec_generic drm_kms_helper edac_mce_amd
>>>>>>>> ledtrig_audio cec rc_core kvm_amd drm ccp snd_hda_codec_hdmi
>>>>>>>> agpgart rng_core kv
>>>>>>>> m snd_hda_intel syscopyarea sysfillrect ppdev sysimgblt
>>>>>>>> snd_intel_dspcfg fb_sys_fops snd_hda_codec snd_hda_core
>>>>>>>> snd_hwdep irqbypass wmi
>>>>>>>> _bmof snd_pcm snd_timer snd evdev pcspkr soundcore parport_pc
>>>>>>>> parport sp5100_tco mac_hid i2c_piix4 k10temp acpi_cpufreq
>>>>>>>> uinput crypto_u
>>>>>>>> ser ip_tables x_tables hid_generic usbhid hid ohci_pci
>>>>>>>> virtio_net net_failover failover firewire_ohci firewire_core
>>>>>>>> crc_itu_t pata_atii
>>>>>>>> xp ehci_pci ehci_hcd sr_mod cdrom ohci_hcd ata_generic
>>>>>>>> pata_acpi pata_jmicron wmi floppy
>>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: r8169 realtek
>>>>>>>> libphy
>>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: CPU: 3 PID: 787
>>>>>>>> Comm: NetworkManager Not tainted 5.7.0-1-raw #12
>>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Hardware name:
>>>>>>>> Gigabyte Technology Co., Ltd.
>>>>>>>> GA-MA790FXT-UD5P/GA-MA790FXT-UD5P, BIOS F8l 07/15/2010
>>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RIP:
>>>>>>>> 0010:phy_save_page+0xb1/0xe3 [libphy]
>>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: Code: c8 82 11 c0
>>>>>>>> e8 06 28 ff cc 85 db 74 47 48 8b 85 48 03 00 00 48 83 b8 68 01
>>>>>>>> 00 00 00 75 10 48 c7 c7 e8 82 11 c0 e8 a9 dd f7 cc <0f> 0b eb
>>>>>>>> 26 48 c7 c7 52 78 11 c0 e8 99 dd f7 cc 0f 0b 48 8b 85 48
>>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RSP:
>>>>>>>> 0018:ffff962c408ef370 EFLAGS: 00010282
>>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RAX:
>>>>>>>> 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
>>>>>>>> touko 02 20:40:04 MinistryOfSillyWalk kernel: RDX:
>>>>>>>> 0000000000000001 RSI: 0000000000000092 RDI: 00000000ffffffff
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: RBP:
>>>>>>>> ffff8b1af3eb8800 R08: 00000000000004b3 R09: 0000000000000004
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R10:
>>>>>>>> 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffa1
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: R13:
>>>>>>>> 0000000000000002 R14: 0000000000000002 R15: ffff8b1af3eb8800
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: FS:
>>>>>>>> 00007f07be5d4d80(0000) GS:ffff8b1af7cc0000(0000)
>>>>>>>> knlGS:0000000000000000
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CS: 0010 DS: 0000
>>>>>>>> ES: 0000 CR0: 0000000080050033
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: CR2:
>>>>>>>> 000055b83aecb008 CR3: 00000002246b0000 CR4: 00000000000006e0
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel: Call Trace:
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>>>>> phy_select_page+0x53/0x7a [libphy]
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>>>>> phy_write_paged+0x5c/0xa0 [libphy]
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>>>>> rtl8168d_1_hw_phy_config+0x9d/0x210 [r8169]
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>>>>> rtl8169_init_phy+0x19/0x110 [r8169]
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>>>>> rtl_open+0x354/0x4d0 [r8169]
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>>>>> __dev_open+0xe0/0x170
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>>>>> __dev_change_flags+0x188/0x1e0
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>>>>> dev_change_flags+0x21/0x60
>>>>>>>> touko 02 20:40:05 MinistryOfSillyWalk kernel:
>>>>>>>> do_setlink+0x78a/0xfd0
>>>>>>>>
>>>>>>>>
>>>>>>>> Something does not setup/register properly at first the way it
>>>>>>>> should.
>>>>>>>>
>>>>>>>>
>>>>>>> I think i solved it: realtek (the phy driver) was missing device
>>>>>>> entry for the PHY ID reported by the NIC to match -> read_page
>>>>>>> and write_page function pointers should now be set. The generic
>>>>>>> PHY does not fill
>>>>>>>
>>>>>>> the driver's functionality to read or write pages. It happens to
>>>>>>> be so that the drivers for |RTL8211B Gigabit Ethernet seems to
>>>>>>> work just fine for my NIC's.
>>>>>> The analysis is wrong. The incorrect PHY ID is not root cause of the
>>>>>> problem, it's caused by a BIOS bug. It's not a valid PHY ID. If
>>>>>> you want
>>>>>> to do something, then you could try to inject a PHY soft reset
>>>>>> before
>>>>>> the MII bus is registered. This should be board-specific, e.g. using
>>>>>> dmi_check_system().
>>>>> Ok, i'll try that approach, thanks for the tip. Hmm, I'll do
>>>>> similar function mapping what the HW init/config function does
>>>>> determine
>>>>>
>>>>> function to use.
>>>>>
>>>>>
>>>>> I'll get back to you when I got something new developed.
>>>>>
>>>> Oujeah, now it works OK.. the soft reset was all it needed.
>>>>
>>>>
>>>> Here's the patch:
>>>>
>>>> From 06c5deacf3ca9f9258431756a41ff0ba1792f1f7 Mon Sep 17 00:00:00
>>>> 2001
>>>> From: Lauri Jakku <lja@iki.fi>
>>>> Date: Thu, 16 Apr 2020 00:38:51 +0300
>>>> Subject: [PATCH] NET: r8169 driver identifying improvement.
>>>>
>>>> Trust device MAC enum + r8169d NIC soft reset
>>>> before configuration.
>>>>
>>>> This commit adds enumeration check and allows
>>>> driver to be slow to attach.
>>>>
>>>> Signed-off-by: Lauri Jakku <lja@iki.fi>
>>>> ---
>>>> drivers/net/ethernet/realtek/r8169_main.c | 24 +++--
>>>> .../net/ethernet/realtek/r8169_phy_config.c | 80 ++++++++++++++++
>>>> drivers/net/phy/phy-core.c | 91
>>>> ++++++++++++++++++-
>>>> 3 files changed, 182 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>> index bf5bf05970a2..a85764f6e448 100644
>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>> @@ -640,7 +640,6 @@ MODULE_AUTHOR("Realtek and the Linux r8169 crew
>>>> <netdev@vger.kernel.org>");
>>>> MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
>>>> module_param_named(debug, debug.msg_enable, int, 0);
>>>> MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ...,
>>>> 16=all)");
>>>> -MODULE_SOFTDEP("pre: realtek");
>>>> MODULE_LICENSE("GPL");
>>>> MODULE_FIRMWARE(FIRMWARE_8168D_1);
>>>> MODULE_FIRMWARE(FIRMWARE_8168D_2);
>>>> @@ -5172,13 +5171,18 @@ static int r8169_mdio_register(struct
>>>> rtl8169_private *tp)
>>>> if (!tp->phydev) {
>>>> mdiobus_unregister(new_bus);
>>>> return -ENODEV;
>>>> - } else if (!tp->phydev->drv) {
>>>> - /* Most chip versions fail with the genphy driver.
>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>> - */
>>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs
>>>> to be added to initramfs?\n");
>>>> - mdiobus_unregister(new_bus);
>>>> - return -EUNATCH;
>>>> + } else {
>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n",
>>>> tp->phydev->phy_id);
>>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>>> +
>>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>>> + /* Most chip versions fail with the genphy driver.
>>>> + * Therefore ensure that the dedicated PHY driver is
>>>> loaded.
>>>> + */
>>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n");
>>>> + mdiobus_unregister(new_bus);
>>>> + return -EUNATCH;
>>>> + }
>>>> }
>>>>
>>>> /* PHY will be woken up in rtl_open() */
>>>> @@ -5513,6 +5517,9 @@ static int rtl_init_one(struct pci_dev *pdev,
>>>> const struct pci_device_id *ent)
>>>> rtl_chip_infos[chipset].name, dev->dev_addr, xid,
>>>> pci_irq_vector(pdev, 0));
>>>>
>>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
>>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>>> +
>>>> if (jumbo_max)
>>>> netif_info(tp, probe, dev,
>>>> "jumbo features [frames: %d bytes, tx
>>>> checksumming: %s]\n",
>>>> @@ -5532,6 +5539,7 @@ static int rtl_init_one(struct pci_dev *pdev,
>>>> const struct pci_device_id *ent)
>>>> return rc;
>>>> }
>>>>
>>>> +
>>>> static struct pci_driver rtl8169_pci_driver = {
>>>> .name = MODULENAME,
>>>> .id_table = rtl8169_pci_tbl,
>>>> diff --git a/drivers/net/ethernet/realtek/r8169_phy_config.c
>>>> b/drivers/net/ethernet/realtek/r8169_phy_config.c
>>>> index b73f7d023e99..73d604c7a8a8 100644
>>>> --- a/drivers/net/ethernet/realtek/r8169_phy_config.c
>>>> +++ b/drivers/net/ethernet/realtek/r8169_phy_config.c
>>>> @@ -1243,6 +1243,84 @@ static void rtl8125_2_hw_phy_config(struct
>>>> rtl8169_private *tp,
>>>> rtl8125_config_eee_phy(phydev);
>>>> }
>>>>
>>>> +
>>>> +static void rtl8168d_hw_phy_pre_config_actions(struct
>>>> rtl8169_private *tp,
>>>> + struct phy_device *phydev)
>>>> +{
>>>> + /* Reset the PHY before configuration. There is BIOS bug that
>>>> gives
>>>> + * random PHY ID when device is not soft resetted first. --lja
>>>> + */
>>>> + genphy_soft_reset(phydev);
>>>> +}
>>>> +
>>>> +
>>>> +
>>>> +void r8169_hw_phy_pre_config_actions(struct rtl8169_private *tp,
>>>> struct phy_device *phydev,
>>>> + enum mac_version ver)
>>>> +{
>>>> + static const rtl_phy_cfg_fct phy_pre_config_actions[] = {
>>>> + /* PCI devices. */
>>>> + [RTL_GIGA_MAC_VER_02] = NULL,
>>>> + [RTL_GIGA_MAC_VER_03] = NULL,
>>>> + [RTL_GIGA_MAC_VER_04] = NULL,
>>>> + [RTL_GIGA_MAC_VER_05] = NULL,
>>>> + [RTL_GIGA_MAC_VER_06] = NULL,
>>>> + /* PCI-E devices. */
>>>> + [RTL_GIGA_MAC_VER_07] = NULL,
>>>> + [RTL_GIGA_MAC_VER_08] = NULL,
>>>> + [RTL_GIGA_MAC_VER_09] = NULL,
>>>> + [RTL_GIGA_MAC_VER_10] = NULL,
>>>> + [RTL_GIGA_MAC_VER_11] = NULL,
>>>> + [RTL_GIGA_MAC_VER_12] = NULL,
>>>> + [RTL_GIGA_MAC_VER_13] = NULL,
>>>> + [RTL_GIGA_MAC_VER_14] = NULL,
>>>> + [RTL_GIGA_MAC_VER_15] = NULL,
>>>> + [RTL_GIGA_MAC_VER_16] = NULL,
>>>> + [RTL_GIGA_MAC_VER_17] = NULL,
>>>> + [RTL_GIGA_MAC_VER_18] = NULL,
>>>> + [RTL_GIGA_MAC_VER_19] = NULL,
>>>> + [RTL_GIGA_MAC_VER_20] = NULL,
>>>> + [RTL_GIGA_MAC_VER_21] = NULL,
>>>> + [RTL_GIGA_MAC_VER_22] = NULL,
>>>> + [RTL_GIGA_MAC_VER_23] = NULL,
>>>> + [RTL_GIGA_MAC_VER_24] = NULL,
>>>> + [RTL_GIGA_MAC_VER_25] = rtl8168d_hw_phy_pre_config_actions,
>>>> + [RTL_GIGA_MAC_VER_26] = rtl8168d_hw_phy_pre_config_actions,
>>>> + [RTL_GIGA_MAC_VER_27] = rtl8168d_hw_phy_pre_config_actions,
>>>> + [RTL_GIGA_MAC_VER_28] = rtl8168d_hw_phy_pre_config_actions,
>>>> + [RTL_GIGA_MAC_VER_29] = NULL,
>>>> + [RTL_GIGA_MAC_VER_30] = NULL,
>>>> + [RTL_GIGA_MAC_VER_31] = NULL,
>>>> + [RTL_GIGA_MAC_VER_32] = NULL,
>>>> + [RTL_GIGA_MAC_VER_33] = NULL,
>>>> + [RTL_GIGA_MAC_VER_34] = NULL,
>>>> + [RTL_GIGA_MAC_VER_35] = NULL,
>>>> + [RTL_GIGA_MAC_VER_36] = NULL,
>>>> + [RTL_GIGA_MAC_VER_37] = NULL,
>>>> + [RTL_GIGA_MAC_VER_38] = NULL,
>>>> + [RTL_GIGA_MAC_VER_39] = NULL,
>>>> + [RTL_GIGA_MAC_VER_40] = NULL,
>>>> + [RTL_GIGA_MAC_VER_41] = NULL,
>>>> + [RTL_GIGA_MAC_VER_42] = NULL,
>>>> + [RTL_GIGA_MAC_VER_43] = NULL,
>>>> + [RTL_GIGA_MAC_VER_44] = NULL,
>>>> + [RTL_GIGA_MAC_VER_45] = NULL,
>>>> + [RTL_GIGA_MAC_VER_46] = NULL,
>>>> + [RTL_GIGA_MAC_VER_47] = NULL,
>>>> + [RTL_GIGA_MAC_VER_48] = NULL,
>>>> + [RTL_GIGA_MAC_VER_49] = NULL,
>>>> + [RTL_GIGA_MAC_VER_50] = NULL,
>>>> + [RTL_GIGA_MAC_VER_51] = NULL,
>>>> + [RTL_GIGA_MAC_VER_52] = NULL,
>>>> + [RTL_GIGA_MAC_VER_60] = NULL,
>>>> + [RTL_GIGA_MAC_VER_61] = NULL,
>>>> + };
>>>> +
>>>> + if (phy_pre_config_actions[ver])
>>>> + phy_pre_config_actions[ver](tp, phydev);
>>>> +}
>>>> +
>>>> +
>>>> void r8169_hw_phy_config(struct rtl8169_private *tp, struct
>>>> phy_device *phydev,
>>>> enum mac_version ver)
>>>> {
>>>> @@ -1303,6 +1381,8 @@ void r8169_hw_phy_config(struct
>>>> rtl8169_private *tp, struct phy_device *phydev,
>>>> [RTL_GIGA_MAC_VER_60] = rtl8125_1_hw_phy_config,
>>>> [RTL_GIGA_MAC_VER_61] = rtl8125_2_hw_phy_config,
>>>> };
>>>> +
>>>> + r8169_hw_phy_pre_config_actions(tp, phydev);
>>>>
>>>> if (phy_configs[ver])
>>>> phy_configs[ver](tp, phydev);
>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>> index 66b8c61ca74c..b170185a1ed1 100644
>>>> --- a/drivers/net/phy/phy-core.c
>>>> +++ b/drivers/net/phy/phy-core.c
>>>> @@ -151,6 +151,25 @@ static const struct phy_setting settings[] = {
>>>> };
>>>> #undef PHY_SETTING
>>>>
>>>> +#ifdef DEBUG
>>>> +#define R8169_ATTACHED_PRINTK \
>>>> + printk("Phy is attached check %s @ %d: %d\n", \
>>>> + __FUNC__, __LINE__, is_attached_check);
>>>> +
>>>> +#else
>>>> +#define R8169_ATTACHED_PRINTK
>>>> +#endif
>>>> +
>>>> +#define PHY_NOT_ATTACHED_CHECK \
>>>> + { \
>>>> + void *attached_dev_ptr = (phydev) ? phydev->attached_dev :
>>>> NULL; \
>>>> + int is_attached_check = (attached_dev_ptr != NULL) && \
>>>> + ((phydev) && (phydev->state >=
>>>> PHY_READY)); \
>>>> + R8169_ATTACHED_PRINTK \
>>>> + if (! is_attached_check ) return -EOPNOTSUPP; \
>>>> + };
>>>> +
>>>> +
>>>> /**
>>>> * phy_lookup_setting - lookup a PHY setting
>>>> * @speed: speed to match
>>>> @@ -457,6 +476,9 @@ int phy_read_mmd(struct phy_device *phydev, int
>>>> devad, u32 regnum)
>>>> {
>>>> int ret;
>>>>
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> phy_lock_mdio_bus(phydev);
>>>> ret = __phy_read_mmd(phydev, devad, regnum);
>>>> phy_unlock_mdio_bus(phydev);
>>>> @@ -479,6 +501,9 @@ int __phy_write_mmd(struct phy_device *phydev,
>>>> int devad, u32 regnum, u16 val)
>>>> {
>>>> int ret;
>>>>
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> if (regnum > (u16)~0 || devad > 32)
>>>> return -EINVAL;
>>>>
>>>> @@ -518,6 +543,9 @@ int phy_write_mmd(struct phy_device *phydev,
>>>> int devad, u32 regnum, u16 val)
>>>> {
>>>> int ret;
>>>>
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> phy_lock_mdio_bus(phydev);
>>>> ret = __phy_write_mmd(phydev, devad, regnum, val);
>>>> phy_unlock_mdio_bus(phydev);
>>>> @@ -543,6 +571,10 @@ int phy_modify_changed(struct phy_device
>>>> *phydev, u32 regnum, u16 mask, u16 set)
>>>> {
>>>> int ret;
>>>>
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> +
>>>> phy_lock_mdio_bus(phydev);
>>>> ret = __phy_modify_changed(phydev, regnum, mask, set);
>>>> phy_unlock_mdio_bus(phydev);
>>>> @@ -587,6 +619,9 @@ int phy_modify(struct phy_device *phydev, u32
>>>> regnum, u16 mask, u16 set)
>>>> {
>>>> int ret;
>>>>
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> phy_lock_mdio_bus(phydev);
>>>> ret = __phy_modify(phydev, regnum, mask, set);
>>>> phy_unlock_mdio_bus(phydev);
>>>> @@ -613,6 +648,9 @@ int __phy_modify_mmd_changed(struct phy_device
>>>> *phydev, int devad, u32 regnum,
>>>> {
>>>> int new, ret;
>>>>
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> ret = __phy_read_mmd(phydev, devad, regnum);
>>>> if (ret < 0)
>>>> return ret;
>>>> @@ -646,6 +684,10 @@ int phy_modify_mmd_changed(struct phy_device
>>>> *phydev, int devad, u32 regnum,
>>>> {
>>>> int ret;
>>>>
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> +
>>>> phy_lock_mdio_bus(phydev);
>>>> ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask,
>>>> set);
>>>> phy_unlock_mdio_bus(phydev);
>>>> @@ -671,6 +713,9 @@ int __phy_modify_mmd(struct phy_device *phydev,
>>>> int devad, u32 regnum,
>>>> {
>>>> int ret;
>>>>
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask,
>>>> set);
>>>>
>>>> return ret < 0 ? ret : 0;
>>>> @@ -694,6 +739,9 @@ int phy_modify_mmd(struct phy_device *phydev,
>>>> int devad, u32 regnum,
>>>> {
>>>> int ret;
>>>>
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> phy_lock_mdio_bus(phydev);
>>>> ret = __phy_modify_mmd(phydev, devad, regnum, mask, set);
>>>> phy_unlock_mdio_bus(phydev);
>>>> @@ -704,7 +752,11 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
>>>>
>>>> static int __phy_read_page(struct phy_device *phydev)
>>>> {
>>>> - if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not
>>>> available, PHY driver not loaded?\n"))
>>>> +
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> + if (WARN(!phydev->drv->read_page, "read_page callback not
>>>> available, PHY driver not loaded?\n"))
>>>> return -EOPNOTSUPP;
>>>>
>>>> return phydev->drv->read_page(phydev);
>>>> @@ -712,12 +764,16 @@ static int __phy_read_page(struct phy_device
>>>> *phydev)
>>>>
>>>> static int __phy_write_page(struct phy_device *phydev, int page)
>>>> {
>>>> - if (WARN_ONCE(!phydev->drv->write_page, "write_page callback
>>>> not available, PHY driver not loaded?\n"))
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> + if (WARN(!phydev->drv->write_page, "write_page callback not
>>>> available, PHY driver not loaded?\n"))
>>>> return -EOPNOTSUPP;
>>>>
>>>> return phydev->drv->write_page(phydev, page);
>>>> }
>>>>
>>>> +
>>>> /**
>>>> * phy_save_page() - take the bus lock and save the current page
>>>> * @phydev: a pointer to a &struct phy_device
>>>> @@ -728,7 +784,11 @@ static int __phy_write_page(struct phy_device
>>>> *phydev, int page)
>>>> */
>>>> int phy_save_page(struct phy_device *phydev)
>>>> {
>>>> - phy_lock_mdio_bus(phydev);
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> +
>>>> + phy_lock_mdio_bus(phydev);
>>>> return __phy_read_page(phydev);
>>>> }
>>>> EXPORT_SYMBOL_GPL(phy_save_page);
>>>> @@ -748,7 +808,10 @@ int phy_select_page(struct phy_device *phydev,
>>>> int page)
>>>> {
>>>> int ret, oldpage;
>>>>
>>>> - oldpage = ret = phy_save_page(phydev);
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> + oldpage = ret = phy_save_page(phydev);
>>>> if (ret < 0)
>>>> return ret;
>>>>
>>>> @@ -782,6 +845,9 @@ int phy_restore_page(struct phy_device *phydev,
>>>> int oldpage, int ret)
>>>> {
>>>> int r;
>>>>
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> if (oldpage >= 0) {
>>>> r = __phy_write_page(phydev, oldpage);
>>>>
>>>> @@ -812,6 +878,9 @@ EXPORT_SYMBOL_GPL(phy_restore_page);
>>>> int phy_read_paged(struct phy_device *phydev, int page, u32 regnum)
>>>> {
>>>> int ret = 0, oldpage;
>>>> +
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>>
>>>> oldpage = phy_select_page(phydev, page);
>>>> if (oldpage >= 0)
>>>> @@ -834,6 +903,10 @@ int phy_write_paged(struct phy_device *phydev,
>>>> int page, u32 regnum, u16 val)
>>>> {
>>>> int ret = 0, oldpage;
>>>>
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> +
>>>> oldpage = phy_select_page(phydev, page);
>>>> if (oldpage >= 0)
>>>> ret = __phy_write(phydev, regnum, val);
>>>> @@ -856,6 +929,9 @@ int phy_modify_paged_changed(struct phy_device
>>>> *phydev, int page, u32 regnum,
>>>> u16 mask, u16 set)
>>>> {
>>>> int ret = 0, oldpage;
>>>> +
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>>
>>>> oldpage = phy_select_page(phydev, page);
>>>> if (oldpage >= 0)
>>>> @@ -878,7 +954,12 @@ EXPORT_SYMBOL(phy_modify_paged_changed);
>>>> int phy_modify_paged(struct phy_device *phydev, int page, u32
>>>> regnum,
>>>> u16 mask, u16 set)
>>>> {
>>>> - int ret = phy_modify_paged_changed(phydev, page, regnum, mask,
>>>> set);
>>>> + int ret = -1;
>>>> +
>>>> + /* If not attached, do nothing. */
>>>> + PHY_NOT_ATTACHED_CHECK;
>>>> +
>>>> + ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
>>>>
>>>> return ret < 0 ? ret : 0;
>>>> }
>>> here is the polished patch:
>>>
>>> From 6dd6f2813c543dc728efb8dca796bbbe870bd031 Mon Sep 17 00:00:00 2001
>>> From: Lauri Jakku <lja@iki.fi>
>>> Date: Thu, 16 Apr 2020 00:38:51 +0300
>>> Subject: [PATCH] NET: r8169 driver identifying improvement.
>>>
>>> Trust device MAC enum + r8169d NIC soft reset
>>> before configuration.
>>>
>>> This commit adds enumeration check and allows
>>> driver to be slow to attach.
>>>
>>> Signed-off-by: Lauri Jakku <lja@iki.fi>
>>> ---
>>> drivers/net/ethernet/realtek/r8169_main.c | 21 +++--
>>> .../net/ethernet/realtek/r8169_phy_config.c | 80
>>> +++++++++++++++++++
>>> 2 files changed, 93 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>> index bf5bf05970a2..6828e755a460 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>> @@ -640,7 +640,6 @@ MODULE_AUTHOR("Realtek and the Linux r8169 crew
>>> <netdev@vger.kernel.org>");
>>> MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
>>> module_param_named(debug, debug.msg_enable, int, 0);
>>> MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ...,
>>> 16=all)");
>>> -MODULE_SOFTDEP("pre: realtek");
>>> MODULE_LICENSE("GPL");
>>> MODULE_FIRMWARE(FIRMWARE_8168D_1);
>>> MODULE_FIRMWARE(FIRMWARE_8168D_2);
>>> @@ -5172,13 +5171,18 @@ static int r8169_mdio_register(struct
>>> rtl8169_private *tp)
>>> if (!tp->phydev) {
>>> mdiobus_unregister(new_bus);
>>> return -ENODEV;
>>> - } else if (!tp->phydev->drv) {
>>> - /* Most chip versions fail with the genphy driver.
>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>> - */
>>> - dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs
>>> to be added to initramfs?\n");
>>> - mdiobus_unregister(new_bus);
>>> - return -EUNATCH;
>>> + } else {
>>> + dev_info(&pdev->dev, "PHY version: 0x%x\n",
>>> tp->phydev->phy_id);
>>> + dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
>>> +
>>> + if (tp->mac_version == RTL_GIGA_MAC_NONE) {
>>> + /* Most chip versions fail with the genphy driver.
>>> + * Therefore ensure that the dedicated PHY driver is
>>> loaded.
>>> + */
>>> + dev_err(&pdev->dev, "Not known MAC/PHY version.\n");
>>> + mdiobus_unregister(new_bus);
>>> + return -EUNATCH;
>>> + }
>>> }
>>>
>>> /* PHY will be woken up in rtl_open() */
>>> @@ -5532,6 +5536,7 @@ static int rtl_init_one(struct pci_dev *pdev,
>>> const struct pci_device_id *ent)
>>> return rc;
>>> }
>>>
>>> +
>>> static struct pci_driver rtl8169_pci_driver = {
>>> .name = MODULENAME,
>>> .id_table = rtl8169_pci_tbl,
>>> diff --git a/drivers/net/ethernet/realtek/r8169_phy_config.c
>>> b/drivers/net/ethernet/realtek/r8169_phy_config.c
>>> index b73f7d023e99..f13f68b79a92 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_phy_config.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_phy_config.c
>>> @@ -1243,6 +1243,84 @@ static void rtl8125_2_hw_phy_config(struct
>>> rtl8169_private *tp,
>>> rtl8125_config_eee_phy(phydev);
>>> }
>>>
>>> +
>>> +static void rtl8168d_hw_phy_pre_config_actions(struct
>>> rtl8169_private *tp,
>>> + struct phy_device *phydev)
>>> +{
>>> + /* Reset the PHY before configuration. There is BIOS bug that
>>> gives
>>> + * random PHY ID when device is not soft resetted first. --lja
>>> + */
>>> + genphy_soft_reset(phydev);
>>> +}
>>> +
>>> +
>>> +
>>> +void r8169_hw_phy_pre_config_actions(struct rtl8169_private *tp,
>>> struct phy_device *phydev,
>>> + enum mac_version ver)
>>> +{
>>> + static const rtl_phy_cfg_fct phy_pre_config_actions[] = {
>>> + /* PCI devices. */
>>> + [RTL_GIGA_MAC_VER_02] = NULL,
>>> + [RTL_GIGA_MAC_VER_03] = NULL,
>>> + [RTL_GIGA_MAC_VER_04] = NULL,
>>> + [RTL_GIGA_MAC_VER_05] = NULL,
>>> + [RTL_GIGA_MAC_VER_06] = NULL,
>>> + /* PCI-E devices. */
>>> + [RTL_GIGA_MAC_VER_07] = NULL,
>>> + [RTL_GIGA_MAC_VER_08] = NULL,
>>> + [RTL_GIGA_MAC_VER_09] = NULL,
>>> + [RTL_GIGA_MAC_VER_10] = NULL,
>>> + [RTL_GIGA_MAC_VER_11] = NULL,
>>> + [RTL_GIGA_MAC_VER_12] = NULL,
>>> + [RTL_GIGA_MAC_VER_13] = NULL,
>>> + [RTL_GIGA_MAC_VER_14] = NULL,
>>> + [RTL_GIGA_MAC_VER_15] = NULL,
>>> + [RTL_GIGA_MAC_VER_16] = NULL,
>>> + [RTL_GIGA_MAC_VER_17] = NULL,
>>> + [RTL_GIGA_MAC_VER_18] = NULL,
>>> + [RTL_GIGA_MAC_VER_19] = NULL,
>>> + [RTL_GIGA_MAC_VER_20] = NULL,
>>> + [RTL_GIGA_MAC_VER_21] = NULL,
>>> + [RTL_GIGA_MAC_VER_22] = NULL,
>>> + [RTL_GIGA_MAC_VER_23] = NULL,
>>> + [RTL_GIGA_MAC_VER_24] = NULL,
>>> + [RTL_GIGA_MAC_VER_25] = rtl8168d_hw_phy_pre_config_actions,
>>> + [RTL_GIGA_MAC_VER_26] = rtl8168d_hw_phy_pre_config_actions,
>>> + [RTL_GIGA_MAC_VER_27] = rtl8168d_hw_phy_pre_config_actions,
>>> + [RTL_GIGA_MAC_VER_28] = rtl8168d_hw_phy_pre_config_actions,
>>> + [RTL_GIGA_MAC_VER_29] = NULL,
>>> + [RTL_GIGA_MAC_VER_30] = NULL,
>>> + [RTL_GIGA_MAC_VER_31] = NULL,
>>> + [RTL_GIGA_MAC_VER_32] = NULL,
>>> + [RTL_GIGA_MAC_VER_33] = NULL,
>>> + [RTL_GIGA_MAC_VER_34] = NULL,
>>> + [RTL_GIGA_MAC_VER_35] = NULL,
>>> + [RTL_GIGA_MAC_VER_36] = NULL,
>>> + [RTL_GIGA_MAC_VER_37] = NULL,
>>> + [RTL_GIGA_MAC_VER_38] = NULL,
>>> + [RTL_GIGA_MAC_VER_39] = NULL,
>>> + [RTL_GIGA_MAC_VER_40] = NULL,
>>> + [RTL_GIGA_MAC_VER_41] = NULL,
>>> + [RTL_GIGA_MAC_VER_42] = NULL,
>>> + [RTL_GIGA_MAC_VER_43] = NULL,
>>> + [RTL_GIGA_MAC_VER_44] = NULL,
>>> + [RTL_GIGA_MAC_VER_45] = NULL,
>>> + [RTL_GIGA_MAC_VER_46] = NULL,
>>> + [RTL_GIGA_MAC_VER_47] = NULL,
>>> + [RTL_GIGA_MAC_VER_48] = NULL,
>>> + [RTL_GIGA_MAC_VER_49] = NULL,
>>> + [RTL_GIGA_MAC_VER_50] = NULL,
>>> + [RTL_GIGA_MAC_VER_51] = NULL,
>>> + [RTL_GIGA_MAC_VER_52] = NULL,
>>> + [RTL_GIGA_MAC_VER_60] = NULL,
>>> + [RTL_GIGA_MAC_VER_61] = NULL,
>>> + };
>>> +
>>> + if (phy_pre_config_actions[ver])
>>> + phy_pre_config_actions[ver](tp, phydev);
>>> +}
>>> +
>>> +
>>> void r8169_hw_phy_config(struct rtl8169_private *tp, struct
>>> phy_device *phydev,
>>> enum mac_version ver)
>>> {
>>> @@ -1304,6 +1382,8 @@ void r8169_hw_phy_config(struct
>>> rtl8169_private *tp, struct phy_device *phydev,
>>> [RTL_GIGA_MAC_VER_61] = rtl8125_2_hw_phy_config,
>>> };
>>>
>>> + r8169_hw_phy_pre_config_actions(tp, phydev, ver);
>>> +
>>> if (phy_configs[ver])
>>> phy_configs[ver](tp, phydev);
>>> }
>> The PHY ID is checked from devm_mdiobus_register(), you're way too late
>> with the soft reset. Also I said if a quirk is needed then it has to be
>> board-specific. This is not a problem of the chip version in general.
>> What you do in r8169_mdio_register() is simply wrong.
>> Last but not least you mix 100 different things in one patch.
>
> There is no devm_mdiobus_register() and the (pre) configuration is
> done way before any registering is done? I check few boots and clean
> up the patch with check tool, and post then.
>
>
net: ethernet: realtek: r8168 / r8169 driver fix.
There is issue with tp->phydev->drv: It never gets non-null value
while driver is probed first time -> modify the driver check to
trust MAC information fetched from HW.
Something does not run/register PHY interface properly ->
the attachment is done way later -> driver does not work
properly.
Function phy_probe is not called in first module loading.
Line from drivers/net/phy/phy_device.c witch is not executed when
loading first time:
--------------------
static int phy_probe(struct device *dev)
{
struct phy_device *phydev = to_phy_device(dev);
struct device_driver *drv = phydev->mdio.dev.driver;
struct phy_driver *phydrv = to_phy_driver(drv);
int err = 0;
phydev->drv = phydrv; <--- This is never done in probe
of r8169_main.c
-------------------
That line is not executed when driver is loaded with modprobe,
but when unload->reload is done, it is ok.
[-- Attachment #2: 0001-net-ethernet-realtek-r8168-r8169-driver-fix.patch --]
[-- Type: text/x-patch, Size: 9696 bytes --]
From 8e687ddb949214d5f9cb581db7d0246af3556a54 Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Sun, 17 May 2020 15:04:51 +0300
Subject: [PATCH] net: ethernet: realtek: r8168 / r8169 driver fix.
There is issue with tp->phydev->drv: It never gets non-null value
while driver is probed first time -> modify the driver check to
trust MAC information fetched from HW.
Something does not run/register PHY interface properly ->
the attachment is done way later -> driver does not work
properly.
Function phy_probe is not called in first module loading.
Line from drivers/net/phy/phy_device.c witch is not executed when
loading first time:
--------------------
static int phy_probe(struct device *dev)
{
struct phy_device *phydev = to_phy_device(dev);
struct device_driver *drv = phydev->mdio.dev.driver;
struct phy_driver *phydrv = to_phy_driver(drv);
int err = 0;
phydev->drv = phydrv; <--- This is never done in probe
of r8169_main.c
-------------------
That line is not executed when driver is loaded with modprobe,
but when load->remove->reload cycle is done, it is ok.
---
drivers/net/ethernet/realtek/r8169_main.c | 20 +++---
drivers/net/phy/phy-core.c | 76 ++++++++++++++++++++++-
drivers/net/phy/phy_device.c | 4 +-
3 files changed, 89 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..1ad5fb591621 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5172,15 +5172,19 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ dev_info(&pdev->dev, "PHY version: 0x%x\n", tp->phydev->phy_id);
+ dev_info(&pdev->dev, "MAC version: %d\n", tp->mac_version);
+
+ if (tp->mac_version == RTL_GIGA_MAC_NONE) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver is loaded.
+ */
+ dev_err(&pdev->dev, "Not known MAC/PHY version.\n", tp->phydev->phy_id);
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
-
/* PHY will be woken up in rtl_open() */
phy_suspend(tp->phydev);
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index 66b8c61ca74c..809ad2f943d3 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -151,6 +151,18 @@ static const struct phy_setting settings[] = {
};
#undef PHY_SETTING
+#define PHY_NOT_ATTACHED_CHECK \
+ { \
+ void *attached_dev_ptr = (phydev) ? phydev->attached_dev : NULL; \
+ if (! ( \
+ (attached_dev_ptr) && \
+ (phydev->state >= PHY_READY) \
+ ) \
+ ) \
+ return -EOPNOTSUPP; \
+ };
+
+
/**
* phy_lookup_setting - lookup a PHY setting
* @speed: speed to match
@@ -457,6 +469,9 @@ int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
{
int ret;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
phy_lock_mdio_bus(phydev);
ret = __phy_read_mmd(phydev, devad, regnum);
phy_unlock_mdio_bus(phydev);
@@ -479,6 +494,9 @@ int __phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
{
int ret;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
if (regnum > (u16)~0 || devad > 32)
return -EINVAL;
@@ -518,6 +536,9 @@ int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
{
int ret;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
phy_lock_mdio_bus(phydev);
ret = __phy_write_mmd(phydev, devad, regnum, val);
phy_unlock_mdio_bus(phydev);
@@ -543,6 +564,9 @@ int phy_modify_changed(struct phy_device *phydev, u32 regnum, u16 mask, u16 set)
{
int ret;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
phy_lock_mdio_bus(phydev);
ret = __phy_modify_changed(phydev, regnum, mask, set);
phy_unlock_mdio_bus(phydev);
@@ -566,6 +590,9 @@ int __phy_modify(struct phy_device *phydev, u32 regnum, u16 mask, u16 set)
{
int ret;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
ret = __phy_modify_changed(phydev, regnum, mask, set);
return ret < 0 ? ret : 0;
@@ -587,6 +614,9 @@ int phy_modify(struct phy_device *phydev, u32 regnum, u16 mask, u16 set)
{
int ret;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
phy_lock_mdio_bus(phydev);
ret = __phy_modify(phydev, regnum, mask, set);
phy_unlock_mdio_bus(phydev);
@@ -613,6 +643,9 @@ int __phy_modify_mmd_changed(struct phy_device *phydev, int devad, u32 regnum,
{
int new, ret;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
ret = __phy_read_mmd(phydev, devad, regnum);
if (ret < 0)
return ret;
@@ -646,6 +679,9 @@ int phy_modify_mmd_changed(struct phy_device *phydev, int devad, u32 regnum,
{
int ret;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
phy_lock_mdio_bus(phydev);
ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask, set);
phy_unlock_mdio_bus(phydev);
@@ -671,6 +707,9 @@ int __phy_modify_mmd(struct phy_device *phydev, int devad, u32 regnum,
{
int ret;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
ret = __phy_modify_mmd_changed(phydev, devad, regnum, mask, set);
return ret < 0 ? ret : 0;
@@ -694,6 +733,9 @@ int phy_modify_mmd(struct phy_device *phydev, int devad, u32 regnum,
{
int ret;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
phy_lock_mdio_bus(phydev);
ret = __phy_modify_mmd(phydev, devad, regnum, mask, set);
phy_unlock_mdio_bus(phydev);
@@ -704,6 +746,10 @@ EXPORT_SYMBOL_GPL(phy_modify_mmd);
static int __phy_read_page(struct phy_device *phydev)
{
+
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
if (WARN_ONCE(!phydev->drv->read_page, "read_page callback not available, PHY driver not loaded?\n"))
return -EOPNOTSUPP;
@@ -712,6 +758,10 @@ static int __phy_read_page(struct phy_device *phydev)
static int __phy_write_page(struct phy_device *phydev, int page)
{
+
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
if (WARN_ONCE(!phydev->drv->write_page, "write_page callback not available, PHY driver not loaded?\n"))
return -EOPNOTSUPP;
@@ -728,6 +778,10 @@ static int __phy_write_page(struct phy_device *phydev, int page)
*/
int phy_save_page(struct phy_device *phydev)
{
+
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
phy_lock_mdio_bus(phydev);
return __phy_read_page(phydev);
}
@@ -748,6 +802,9 @@ int phy_select_page(struct phy_device *phydev, int page)
{
int ret, oldpage;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
oldpage = ret = phy_save_page(phydev);
if (ret < 0)
return ret;
@@ -782,6 +839,9 @@ int phy_restore_page(struct phy_device *phydev, int oldpage, int ret)
{
int r;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
if (oldpage >= 0) {
r = __phy_write_page(phydev, oldpage);
@@ -813,6 +873,9 @@ int phy_read_paged(struct phy_device *phydev, int page, u32 regnum)
{
int ret = 0, oldpage;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
oldpage = phy_select_page(phydev, page);
if (oldpage >= 0)
ret = __phy_read(phydev, regnum);
@@ -834,6 +897,9 @@ int phy_write_paged(struct phy_device *phydev, int page, u32 regnum, u16 val)
{
int ret = 0, oldpage;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
oldpage = phy_select_page(phydev, page);
if (oldpage >= 0)
ret = __phy_write(phydev, regnum, val);
@@ -857,6 +923,9 @@ int phy_modify_paged_changed(struct phy_device *phydev, int page, u32 regnum,
{
int ret = 0, oldpage;
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
oldpage = phy_select_page(phydev, page);
if (oldpage >= 0)
ret = __phy_modify_changed(phydev, regnum, mask, set);
@@ -878,7 +947,12 @@ EXPORT_SYMBOL(phy_modify_paged_changed);
int phy_modify_paged(struct phy_device *phydev, int page, u32 regnum,
u16 mask, u16 set)
{
- int ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
+ int ret;
+
+ /* If phy not attached, do nothing */
+ PHY_NOT_ATTACHED_CHECK
+
+ ret = phy_modify_paged_changed(phydev, page, regnum, mask, set);
return ret < 0 ? ret : 0;
}
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index ac2784192472..3aff74bfead0 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1352,8 +1352,6 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
phydev->interface = interface;
- phydev->state = PHY_READY;
-
/* Initial carrier state is off as the phy is about to be
* (re)initialized.
*/
@@ -1371,6 +1369,8 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
phy_resume(phydev);
phy_led_triggers_register(phydev);
+ phydev->state = PHY_READY;
+
return err;
error:
--
2.26.2
^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2020-04-15 16:18 ` Heiner Kallweit
[not found] ` <4860e57e-93e4-24f5-6103-fa80acbdfa0d@pp.inet.fi>
@ 2021-03-11 16:00 ` gmail
2021-03-11 16:23 ` Heiner Kallweit
1 sibling, 1 reply; 57+ messages in thread
From: gmail @ 2021-03-11 16:00 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com
<mailto:hkallweit1@gmail.com>> kirjoitti:
On 15.04.2020 16:39, Lauri Jakku wrote:
Hi, There seems to he Something odd problem, maybe timing
related. Stripped version not workingas expected. I get back to
you, when i have it working.
There's no point in working on your patch. W/o proper justification it
isn't acceptable anyway. And so far we still don't know which problem
you actually have.
FIRST please provide the requested logs and explain the actual problem
(incl. the commit that caused the regression).
13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com
<mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll
strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote: On
Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi,
Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On
Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From
2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020
13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix
The driver installation determination made properly by checking
PHY vs DRIVER id's. ---
drivers/net/ethernet/realtek/r8169_main.c | 70
++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2
files changed, 72 insertions(+), 9 deletions(-) I would say that
most of the code is debug prints. I tought that they are helpful
to keep, they are using the debug calls, so they are not visible
if user does not like those. You are missing the point of who
are your users. Users want to have working device and the code.
They don't need or like to debug their kernel. Thanks
Hi, now i got time to tackle with this again :) .. I know the proposed fix is quite hack, BUT it does give a clue what is wrong.
Something in subsystem is not working at the first time, but it needs to be reloaded to work ok (second time). So what I will do
is that I try out re-do the module load within the module, if there is known HW id available but driver is not available, that
would be much nicer and user friendly way.
When the module setup it self nicely on first load, then can be the hunt for late-init of subsystem be checked out. Is the HW
not brought up correct way during first time, or does the HW need time to brough up, or what is the cause.
The justification is the same as all HW driver bugs, the improvement is always better to take in. Or do this patch have some-
thing what other patches do not?
Is there legit reason why NOT to improve something, that is clearly issue for others also than just me ? I will take on the
task to fiddle with the module to get it more-less hacky and fully working version. Without the need for user to do something
for the module to work.
--Lauri J.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2021-03-11 16:00 ` gmail
@ 2021-03-11 16:23 ` Heiner Kallweit
2021-03-11 16:43 ` gmail
0 siblings, 1 reply; 57+ messages in thread
From: Heiner Kallweit @ 2021-03-11 16:23 UTC (permalink / raw)
To: ljakku77; +Cc: Leon Romanovsky, netdev, nic_swsd
On 11.03.2021 17:00, gmail wrote:
> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>
> On 15.04.2020 16:39, Lauri Jakku wrote:
>
> Hi, There seems to he Something odd problem, maybe timing
> related. Stripped version not workingas expected. I get back to
> you, when i have it working.
>
> There's no point in working on your patch. W/o proper justification it
> isn't acceptable anyway. And so far we still don't know which problem
> you actually have.
> FIRST please provide the requested logs and explain the actual problem
> (incl. the commit that caused the regression).
>
>
>
> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com
> <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll
> strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote: On
> Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi,
> Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On
> Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From
> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
> 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020
> 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix
> The driver installation determination made properly by checking
> PHY vs DRIVER id's. ---
> drivers/net/ethernet/realtek/r8169_main.c | 70
> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2
> files changed, 72 insertions(+), 9 deletions(-) I would say that
> most of the code is debug prints. I tought that they are helpful
> to keep, they are using the debug calls, so they are not visible
> if user does not like those. You are missing the point of who
> are your users. Users want to have working device and the code.
> They don't need or like to debug their kernel. Thanks
>
> Hi, now i got time to tackle with this again :) .. I know the proposed fix is quite hack, BUT it does give a clue what is wrong.
>
> Something in subsystem is not working at the first time, but it needs to be reloaded to work ok (second time). So what I will do
> is that I try out re-do the module load within the module, if there is known HW id available but driver is not available, that
> would be much nicer and user friendly way.
>
>
> When the module setup it self nicely on first load, then can be the hunt for late-init of subsystem be checked out. Is the HW
> not brought up correct way during first time, or does the HW need time to brough up, or what is the cause.
>
> The justification is the same as all HW driver bugs, the improvement is always better to take in. Or do this patch have some-
> thing what other patches do not?
>
> Is there legit reason why NOT to improve something, that is clearly issue for others also than just me ? I will take on the
> task to fiddle with the module to get it more-less hacky and fully working version. Without the need for user to do something
> for the module to work.
>
> --Lauri J.
>
>
I have no clue what you're trying to say. The last patch wasn't acceptable at all.
If you want to submit a patch:
- Follow kernel code style
- Explain what the exact problem is, what the root cause is, and how your patch fixes it
- Explain why you're sure that it doesn't break processing on other chip versions
and systems.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2021-03-11 16:23 ` Heiner Kallweit
@ 2021-03-11 16:43 ` gmail
2021-08-10 21:50 ` Late @ Gmail
0 siblings, 1 reply; 57+ messages in thread
From: gmail @ 2021-03-11 16:43 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Heiner Kallweit kirjoitti 11.3.2021 klo 18.23:
> On 11.03.2021 17:00, gmail wrote:
>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>
>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>
>> Hi, There seems to he Something odd problem, maybe timing
>> related. Stripped version not workingas expected. I get back to
>> you, when i have it working.
>>
>> There's no point in working on your patch. W/o proper justification it
>> isn't acceptable anyway. And so far we still don't know which problem
>> you actually have.
>> FIRST please provide the requested logs and explain the actual problem
>> (incl. the commit that caused the regression).
>>
>>
>>
>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com
>> <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll
>> strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote: On
>> Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi,
>> Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On
>> Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From
>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
>> 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020
>> 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix
>> The driver installation determination made properly by checking
>> PHY vs DRIVER id's. ---
>> drivers/net/ethernet/realtek/r8169_main.c | 70
>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2
>> files changed, 72 insertions(+), 9 deletions(-) I would say that
>> most of the code is debug prints. I tought that they are helpful
>> to keep, they are using the debug calls, so they are not visible
>> if user does not like those. You are missing the point of who
>> are your users. Users want to have working device and the code.
>> They don't need or like to debug their kernel. Thanks
>>
>> Hi, now i got time to tackle with this again :) .. I know the proposed fix is quite hack, BUT it does give a clue what is wrong.
>>
>> Something in subsystem is not working at the first time, but it needs to be reloaded to work ok (second time). So what I will do
>> is that I try out re-do the module load within the module, if there is known HW id available but driver is not available, that
>> would be much nicer and user friendly way.
>>
>>
>> When the module setup it self nicely on first load, then can be the hunt for late-init of subsystem be checked out. Is the HW
>> not brought up correct way during first time, or does the HW need time to brough up, or what is the cause.
>>
>> The justification is the same as all HW driver bugs, the improvement is always better to take in. Or do this patch have some-
>> thing what other patches do not?
>>
>> Is there legit reason why NOT to improve something, that is clearly issue for others also than just me ? I will take on the
>> task to fiddle with the module to get it more-less hacky and fully working version. Without the need for user to do something
>> for the module to work.
>>
>> --Lauri J.
>>
>>
> I have no clue what you're trying to say. The last patch wasn't acceptable at all.
> If you want to submit a patch:
>
> - Follow kernel code style
> - Explain what the exact problem is, what the root cause is, and how your patch fixes it
> - Explain why you're sure that it doesn't break processing on other chip versions
> and systems.
>
Ok, i'll make nice patch that has in comment what is the problem and how
does the patch help the case at hand.
I don't know the rootcause, but something in subsystem that possibly is
initializing bit slowly, cause the reloading
of the module provides working network connection, when done via insmod
cycle. I'm not sure is it just a timing
issue or what. I'd like to check where is the driver pointer populated,
and put some debugs to see if the issue is just
timing, let's see.
The problem is that (1st load) fails, but there is valid HW found (the
ID is known), when the hacky patch of mine
is applied, the second time of loading module works ok, and network is
connected ok etc.
I make the change so that when the current HEAD code is going to return
failure, i do check that if the HW id is read ok
from the HW, then pass -EAGAIN ja try to load 5 times, sleeping 250ms in
between.
--Lauri J.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2021-03-11 16:43 ` gmail
@ 2021-08-10 21:50 ` Late @ Gmail
2021-08-11 6:09 ` Heiner Kallweit
0 siblings, 1 reply; 57+ messages in thread
From: Late @ Gmail @ 2021-08-10 21:50 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi,
Now I solved the reloading issue, and r8169 driver works line charm.
Patch:
From: Lauri Jakku <lja@lja.fi>
Date: Mon, 9 Aug 2021 21:44:53 +0300
Subject: [PATCH] net:realtek:r8169 driver load fix
net:realtek:r8169 driver load fix
Problem:
The problem is that (1st load) fails, but there is valid
HW found (the ID is known) and this patch is applied, the second
time of loading module works ok, and network is connected ok
etc.
Solution:
The driver will trust the HW that reports valid ID and then make
re-loading of the module as it would being reloaded manually.
I do check that if the HW id is read ok from the HW, then pass
-EAGAIN ja try to load 5 times, sleeping 250ms in between.
Signed-off-by: Lauri Jakku <lja@lja.fi>
diff --git a/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c b/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
index c7af5bc3b..d8e602527 100644
--- a/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
+++ b/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
@@ -634,6 +634,8 @@ struct rtl8169_private {
struct rtl_fw *rtl_fw;
u32 ocp_base;
+
+ int retry_probeing;
};
typedef void (*rtl_generic_fct)(struct rtl8169_private *tp);
@@ -5097,13 +5099,16 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
tp->phydev = mdiobus_get_phy(new_bus, 0);
if (!tp->phydev) {
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
+ } else if (tp->phydev->phy_id != RTL_GIGA_MAC_NONE) {
+ /* Most chip versions fail with the genphy driver, BUT do rerport valid IW
+ * ID. Re-starting the module seem to fix the issue of non-functional driver.
*/
- dev_err(&pdev->dev, "no dedicated PHY driver found for PHY ID 0x%08x, maybe realtek.ko needs to be added to initramfs?\n",
+ dev_err(&pdev->dev,
+ "no dedicated driver, but HW found: PHY PHY ID 0x%08x\n",
tp->phydev->phy_id);
- return -EUNATCH;
+
+ dev_err(&pdev->dev, "trying re-probe few times..\n");
+
}
tp->phydev->mac_managed_pm = 1;
@@ -5250,6 +5255,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
enum mac_version chipset;
struct net_device *dev;
u16 xid;
+ int savederr = 0;
dev = devm_alloc_etherdev(&pdev->dev, sizeof (*tp));
if (!dev)
@@ -5261,6 +5267,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->dev = dev;
tp->pci_dev = pdev;
tp->supports_gmii = ent->driver_data == RTL_CFG_NO_GBIT ? 0 : 1;
+ tp->retry_probeing = 0;
tp->eee_adv = -1;
tp->ocp_base = OCP_STD_PHY_BASE;
@@ -5410,7 +5417,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, tp);
- rc = r8169_mdio_register(tp);
+ savederr = r8169_mdio_register(tp);
+
+ if (
+ (tp->retry_probeing > 0) &&
+ (savederr == -EAGAIN)
+ ) {
+ netdev_info(dev, " retry of probe requested..............");
+ }
+
if (rc)
return rc;
@@ -5435,6 +5450,14 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (pci_dev_run_wake(pdev))
pm_runtime_put_sync(&pdev->dev);
+ if (
+ (tp->retry_probeing > 0) &&
+ (savederr == -EAGAIN)
+ ) {
+ netdev_info(dev, " retry of probe requested..............");
+ return savederr;
+ }
+
return 0;
}
diff --git a/linux-5.14-rc4/drivers/net/phy/phy_device.c b/linux-5.14-rc4/drivers/net/phy/phy_device.c
index 5d5f9a9ee..59c6ac031 100644
--- a/linux-5.14-rc4/drivers/net/phy/phy_device.c
+++ b/linux-5.14-rc4/drivers/net/phy/phy_device.c
@@ -2980,6 +2980,9 @@ struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode)
}
EXPORT_SYMBOL_GPL(fwnode_get_phy_node);
+
+static int phy_remove(struct device *dev);
+
/**
* phy_probe - probe and init a PHY device
* @dev: device to probe and init
@@ -2988,13 +2991,22 @@ EXPORT_SYMBOL_GPL(fwnode_get_phy_node);
* set the state to READY (the driver's init function should
* set it to STARTING if needed).
*/
+#define REDO_PROBE_TIMES 5
static int phy_probe(struct device *dev)
{
struct phy_device *phydev = to_phy_device(dev);
struct device_driver *drv = phydev->mdio.dev.driver;
struct phy_driver *phydrv = to_phy_driver(drv);
+ int again = 0;
+ int savederr = 0;
+again_retry:
int err = 0;
+ if (again > 0) {
+ pr_err("%s: Re-probe %d of driver.....\n",
+ phydrv->name, again);
+ }
+
phydev->drv = phydrv;
/* Disable the interrupt if the PHY doesn't support it
@@ -3013,6 +3025,17 @@ static int phy_probe(struct device *dev)
if (phydev->drv->probe) {
err = phydev->drv->probe(phydev);
+
+ /* If again requested. */
+ if (err == -EAGAIN) {
+ again++;
+ savederr = err;
+ err = 0;
+
+ pr_info("%s: EAGAIN: %d ...\n",
+ phydrv->name, again);
+ }
+
if (err)
goto out;
}
@@ -3081,6 +3104,20 @@ static int phy_probe(struct device *dev)
mutex_unlock(&phydev->lock);
+ if ((savederr == -EAGAIN) &&
+ ((again > 0) && (again < REDO_PROBE_TIMES))
+ ) {
+ pr_err("%s: Retry removal driver..\n",
+ phydrv->name);
+
+ phy_remove(dev);
+
+ pr_err("%s: Re-probe driver..\n",
+ phydrv->name);
+ savederr = 0;
+ goto again_retry;
+ }
+
return err;
}
@@ -3108,6 +3145,7 @@ static int phy_remove(struct device *dev)
return 0;
}
+
static void phy_shutdown(struct device *dev)
{
struct phy_device *phydev = to_phy_device(dev);
On 11.3.2021 18.43, gmail wrote:
>
> Heiner Kallweit kirjoitti 11.3.2021 klo 18.23:
>> On 11.03.2021 17:00, gmail wrote:
>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>
>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>
>>> Hi, There seems to he Something odd problem, maybe timing
>>> related. Stripped version not workingas expected. I get back to
>>> you, when i have it working.
>>>
>>> There's no point in working on your patch. W/o proper justification it
>>> isn't acceptable anyway. And so far we still don't know which problem
>>> you actually have.
>>> FIRST please provide the requested logs and explain the actual problem
>>> (incl. the commit that caused the regression).
>>>
>>>
>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com
>>> <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll
>>> strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote: On
>>> Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi,
>>> Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On
>>> Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From
>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
>>> 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020
>>> 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix
>>> The driver installation determination made properly by checking
>>> PHY vs DRIVER id's. ---
>>> drivers/net/ethernet/realtek/r8169_main.c | 70
>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2
>>> files changed, 72 insertions(+), 9 deletions(-) I would say that
>>> most of the code is debug prints. I tought that they are helpful
>>> to keep, they are using the debug calls, so they are not visible
>>> if user does not like those. You are missing the point of who
>>> are your users. Users want to have working device and the code.
>>> They don't need or like to debug their kernel. Thanks
>>>
>>> Hi, now i got time to tackle with this again :) .. I know the proposed fix is quite hack, BUT it does give a clue what is wrong.
>>>
>>> Something in subsystem is not working at the first time, but it needs to be reloaded to work ok (second time). So what I will do
>>> is that I try out re-do the module load within the module, if there is known HW id available but driver is not available, that
>>> would be much nicer and user friendly way.
>>>
>>>
>>> When the module setup it self nicely on first load, then can be the hunt for late-init of subsystem be checked out. Is the HW
>>> not brought up correct way during first time, or does the HW need time to brough up, or what is the cause.
>>>
>>> The justification is the same as all HW driver bugs, the improvement is always better to take in. Or do this patch have some-
>>> thing what other patches do not?
>>>
>>> Is there legit reason why NOT to improve something, that is clearly issue for others also than just me ? I will take on the
>>> task to fiddle with the module to get it more-less hacky and fully working version. Without the need for user to do something
>>> for the module to work.
>>>
>>> --Lauri J.
>>>
>>>
>> I have no clue what you're trying to say. The last patch wasn't acceptable at all.
>> If you want to submit a patch:
>>
>> - Follow kernel code style
>> - Explain what the exact problem is, what the root cause is, and how your patch fixes it
>> - Explain why you're sure that it doesn't break processing on other chip versions
>> and systems.
>>
> Ok, i'll make nice patch that has in comment what is the problem and how does the patch help the case at hand.
>
> I don't know the rootcause, but something in subsystem that possibly is initializing bit slowly, cause the reloading
>
> of the module provides working network connection, when done via insmod cycle. I'm not sure is it just a timing
>
> issue or what. I'd like to check where is the driver pointer populated, and put some debugs to see if the issue is just
>
> timing, let's see.
>
>
> The problem is that (1st load) fails, but there is valid HW found (the ID is known), when the hacky patch of mine
>
> is applied, the second time of loading module works ok, and network is connected ok etc.
>
>
> I make the change so that when the current HEAD code is going to return failure, i do check that if the HW id is read ok
>
> from the HW, then pass -EAGAIN ja try to load 5 times, sleeping 250ms in between.
>
>
> --Lauri J.
>
>
>
>
^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2021-08-10 21:50 ` Late @ Gmail
@ 2021-08-11 6:09 ` Heiner Kallweit
2021-08-11 13:17 ` Late @ Gmail
0 siblings, 1 reply; 57+ messages in thread
From: Heiner Kallweit @ 2021-08-11 6:09 UTC (permalink / raw)
To: ljakku77; +Cc: Leon Romanovsky, netdev, nic_swsd
On 10.08.2021 23:50, Late @ Gmail wrote:
> Hi,
>
> Now I solved the reloading issue, and r8169 driver works line charm.
>
This patch is a complete hack and and in parts simply wrong.
In addition it misses the basics of how to submit a patch.
Quality hasn't improved since your first attempt, so better stop
trying to submit this to mainline.
> Patch:
>
> From: Lauri Jakku <lja@lja.fi>
> Date: Mon, 9 Aug 2021 21:44:53 +0300
> Subject: [PATCH] net:realtek:r8169 driver load fix
>
> net:realtek:r8169 driver load fix
>
> Problem:
>
> The problem is that (1st load) fails, but there is valid
> HW found (the ID is known) and this patch is applied, the second
> time of loading module works ok, and network is connected ok
> etc.
>
> Solution:
>
> The driver will trust the HW that reports valid ID and then make
> re-loading of the module as it would being reloaded manually.
>
> I do check that if the HW id is read ok from the HW, then pass
> -EAGAIN ja try to load 5 times, sleeping 250ms in between.
>
> Signed-off-by: Lauri Jakku <lja@lja.fi>
> diff --git a/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c b/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
> index c7af5bc3b..d8e602527 100644
> --- a/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
> @@ -634,6 +634,8 @@ struct rtl8169_private {
> struct rtl_fw *rtl_fw;
>
> u32 ocp_base;
> +
> + int retry_probeing;
> };
>
> typedef void (*rtl_generic_fct)(struct rtl8169_private *tp);
> @@ -5097,13 +5099,16 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
> tp->phydev = mdiobus_get_phy(new_bus, 0);
> if (!tp->phydev) {
> return -ENODEV;
> - } else if (!tp->phydev->drv) {
> - /* Most chip versions fail with the genphy driver.
> - * Therefore ensure that the dedicated PHY driver is loaded.
> + } else if (tp->phydev->phy_id != RTL_GIGA_MAC_NONE) {
You compare two completely different things here. The phy_id has nothing
to do with the chip version enum.
> + /* Most chip versions fail with the genphy driver, BUT do rerport valid IW
> + * ID. Re-starting the module seem to fix the issue of non-functional driver.
> */
> - dev_err(&pdev->dev, "no dedicated PHY driver found for PHY ID 0x%08x, maybe realtek.ko needs to be added to initramfs?\n",
> + dev_err(&pdev->dev,
> + "no dedicated driver, but HW found: PHY PHY ID 0x%08x\n",
> tp->phydev->phy_id);
> - return -EUNATCH;
> +
> + dev_err(&pdev->dev, "trying re-probe few times..\n");
> +
> }
>
> tp->phydev->mac_managed_pm = 1;
> @@ -5250,6 +5255,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> enum mac_version chipset;
> struct net_device *dev;
> u16 xid;
> + int savederr = 0;
>
> dev = devm_alloc_etherdev(&pdev->dev, sizeof (*tp));
> if (!dev)
> @@ -5261,6 +5267,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> tp->dev = dev;
> tp->pci_dev = pdev;
> tp->supports_gmii = ent->driver_data == RTL_CFG_NO_GBIT ? 0 : 1;
> + tp->retry_probeing = 0;
> tp->eee_adv = -1;
> tp->ocp_base = OCP_STD_PHY_BASE;
>
> @@ -5410,7 +5417,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>
> pci_set_drvdata(pdev, tp);
>
> - rc = r8169_mdio_register(tp);
> + savederr = r8169_mdio_register(tp);
> +
> + if (
> + (tp->retry_probeing > 0) &&
> + (savederr == -EAGAIN)
> + ) {
> + netdev_info(dev, " retry of probe requested..............");
> + }
> +
> if (rc)
> return rc;
>
> @@ -5435,6 +5450,14 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (pci_dev_run_wake(pdev))
> pm_runtime_put_sync(&pdev->dev);
>
> + if (
> + (tp->retry_probeing > 0) &&
> + (savederr == -EAGAIN)
> + ) {
> + netdev_info(dev, " retry of probe requested..............");
> + return savederr;
You can not simply return here. You have to clean up.
> + }
> +
> return 0;
> }
>
> diff --git a/linux-5.14-rc4/drivers/net/phy/phy_device.c b/linux-5.14-rc4/drivers/net/phy/phy_device.c
> index 5d5f9a9ee..59c6ac031 100644
No mixing of changes in phylib and drivers.
> --- a/linux-5.14-rc4/drivers/net/phy/phy_device.c
> +++ b/linux-5.14-rc4/drivers/net/phy/phy_device.c
> @@ -2980,6 +2980,9 @@ struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode)
> }
> EXPORT_SYMBOL_GPL(fwnode_get_phy_node);
>
> +
> +static int phy_remove(struct device *dev);
> +
No forward declarations.
> /**
> * phy_probe - probe and init a PHY device
> * @dev: device to probe and init
> @@ -2988,13 +2991,22 @@ EXPORT_SYMBOL_GPL(fwnode_get_phy_node);
> * set the state to READY (the driver's init function should
> * set it to STARTING if needed).
> */
> +#define REDO_PROBE_TIMES 5
> static int phy_probe(struct device *dev)
> {
> struct phy_device *phydev = to_phy_device(dev);
> struct device_driver *drv = phydev->mdio.dev.driver;
> struct phy_driver *phydrv = to_phy_driver(drv);
> + int again = 0;
> + int savederr = 0;
> +again_retry:
> int err = 0;
>
> + if (again > 0) {
> + pr_err("%s: Re-probe %d of driver.....\n",
> + phydrv->name, again);
> + }
> +
> phydev->drv = phydrv;
>
> /* Disable the interrupt if the PHY doesn't support it
> @@ -3013,6 +3025,17 @@ static int phy_probe(struct device *dev)
>
> if (phydev->drv->probe) {
> err = phydev->drv->probe(phydev);
> +
> + /* If again requested. */
> + if (err == -EAGAIN) {
This doesn't make sense. You check the PHY driver probe return code,
mixing it up with the MAC driver return code.
> + again++;
> + savederr = err;
> + err = 0;
> +
> + pr_info("%s: EAGAIN: %d ...\n",
> + phydrv->name, again);
> + }
> +
> if (err)
> goto out;
> }
> @@ -3081,6 +3104,20 @@ static int phy_probe(struct device *dev)
>
> mutex_unlock(&phydev->lock);
>
> + if ((savederr == -EAGAIN) &&
> + ((again > 0) && (again < REDO_PROBE_TIMES))
> + ) {
> + pr_err("%s: Retry removal driver..\n",
> + phydrv->name);
> +
> + phy_remove(dev);
> +
> + pr_err("%s: Re-probe driver..\n",
> + phydrv->name);
> + savederr = 0;
> + goto again_retry;
> + }
> +
> return err;
> }
>
> @@ -3108,6 +3145,7 @@ static int phy_remove(struct device *dev)
> return 0;
> }
>
> +
> static void phy_shutdown(struct device *dev)
> {
> struct phy_device *phydev = to_phy_device(dev);
>
>
>
> On 11.3.2021 18.43, gmail wrote:
>>
>> Heiner Kallweit kirjoitti 11.3.2021 klo 18.23:
>>> On 11.03.2021 17:00, gmail wrote:
>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>
>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>
>>>> Hi, There seems to he Something odd problem, maybe timing
>>>> related. Stripped version not workingas expected. I get back to
>>>> you, when i have it working.
>>>>
>>>> There's no point in working on your patch. W/o proper justification it
>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>> you actually have.
>>>> FIRST please provide the requested logs and explain the actual problem
>>>> (incl. the commit that caused the regression).
>>>>
>>>>
>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com
>>>> <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll
>>>> strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote: On
>>>> Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi,
>>>> Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On
>>>> Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From
>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
>>>> 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020
>>>> 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>> The driver installation determination made properly by checking
>>>> PHY vs DRIVER id's. ---
>>>> drivers/net/ethernet/realtek/r8169_main.c | 70
>>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2
>>>> files changed, 72 insertions(+), 9 deletions(-) I would say that
>>>> most of the code is debug prints. I tought that they are helpful
>>>> to keep, they are using the debug calls, so they are not visible
>>>> if user does not like those. You are missing the point of who
>>>> are your users. Users want to have working device and the code.
>>>> They don't need or like to debug their kernel. Thanks
>>>>
>>>> Hi, now i got time to tackle with this again :) .. I know the proposed fix is quite hack, BUT it does give a clue what is wrong.
>>>>
>>>> Something in subsystem is not working at the first time, but it needs to be reloaded to work ok (second time). So what I will do
>>>> is that I try out re-do the module load within the module, if there is known HW id available but driver is not available, that
>>>> would be much nicer and user friendly way.
>>>>
>>>>
>>>> When the module setup it self nicely on first load, then can be the hunt for late-init of subsystem be checked out. Is the HW
>>>> not brought up correct way during first time, or does the HW need time to brough up, or what is the cause.
>>>>
>>>> The justification is the same as all HW driver bugs, the improvement is always better to take in. Or do this patch have some-
>>>> thing what other patches do not?
>>>>
>>>> Is there legit reason why NOT to improve something, that is clearly issue for others also than just me ? I will take on the
>>>> task to fiddle with the module to get it more-less hacky and fully working version. Without the need for user to do something
>>>> for the module to work.
>>>>
>>>> --Lauri J.
>>>>
>>>>
>>> I have no clue what you're trying to say. The last patch wasn't acceptable at all.
>>> If you want to submit a patch:
>>>
>>> - Follow kernel code style
>>> - Explain what the exact problem is, what the root cause is, and how your patch fixes it
>>> - Explain why you're sure that it doesn't break processing on other chip versions
>>> and systems.
>>>
>> Ok, i'll make nice patch that has in comment what is the problem and how does the patch help the case at hand.
>>
>> I don't know the rootcause, but something in subsystem that possibly is initializing bit slowly, cause the reloading
>>
>> of the module provides working network connection, when done via insmod cycle. I'm not sure is it just a timing
>>
>> issue or what. I'd like to check where is the driver pointer populated, and put some debugs to see if the issue is just
>>
>> timing, let's see.
>>
>>
>> The problem is that (1st load) fails, but there is valid HW found (the ID is known), when the hacky patch of mine
>>
>> is applied, the second time of loading module works ok, and network is connected ok etc.
>>
>>
>> I make the change so that when the current HEAD code is going to return failure, i do check that if the HW id is read ok
>>
>> from the HW, then pass -EAGAIN ja try to load 5 times, sleeping 250ms in between.
>>
>>
>> --Lauri J.
>>
>>
>>
>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2021-08-11 6:09 ` Heiner Kallweit
@ 2021-08-11 13:17 ` Late @ Gmail
2021-08-11 19:47 ` Heiner Kallweit
0 siblings, 1 reply; 57+ messages in thread
From: Late @ Gmail @ 2021-08-11 13:17 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Leon Romanovsky, netdev, nic_swsd
Hi All,
Ok, I will not send patch with the hacky-stuff anymore. I do realize the hacky stuff is not acceptable, but it is a starting point
.. you gotta start from somewhere, and get some comments about the patch.
That means that I need some help, what i'm trying to grasp is what the patch does, so that the driver
works with my HW (witch needs the patch (hacky yeah) to work out of the boot ok).
The modprobe reload does something to driver/hw/??? that it is ok, when the module's probe return zero at all times.
.. that is hacky partly reason: I'm not familiar with kernel's code base yet -> It may seem hacky for many, but i'm
trying to get picture in my head what and why works like it works.
The hacky-bit works for me -> in principle the way to fix in concept is ok, now just to make it non-hacky and align
with current architechture and design of overall kernel codebase.
hmm, i'm thinking of debugging the module's reloading steps with stacktraces to figure out more and
possibly make quirk bit(s) for re-probe within initial module load & handle unloading properly in
between.
So basicly what i'm trying to reproduce in boot-time is:
modprobe -r r8169
modprobe r8169
Sequence.
--Lauri
On 11.8.2021 9.09, Heiner Kallweit wrote:
> On 10.08.2021 23:50, Late @ Gmail wrote:
>> Hi,
>>
>> Now I solved the reloading issue, and r8169 driver works line charm.
>>
> This patch is a complete hack and and in parts simply wrong.
> In addition it misses the basics of how to submit a patch.
> Quality hasn't improved since your first attempt, so better stop
> trying to submit this to mainline.
>
>> Patch:
>>
>> From: Lauri Jakku <lja@lja.fi>
>> Date: Mon, 9 Aug 2021 21:44:53 +0300
>> Subject: [PATCH] net:realtek:r8169 driver load fix
>>
>> net:realtek:r8169 driver load fix
>>
>> Problem:
>>
>> The problem is that (1st load) fails, but there is valid
>> HW found (the ID is known) and this patch is applied, the second
>> time of loading module works ok, and network is connected ok
>> etc.
>>
>> Solution:
>>
>> The driver will trust the HW that reports valid ID and then make
>> re-loading of the module as it would being reloaded manually.
>>
>> I do check that if the HW id is read ok from the HW, then pass
>> -EAGAIN ja try to load 5 times, sleeping 250ms in between.
>>
>> Signed-off-by: Lauri Jakku <lja@lja.fi>
>> diff --git a/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c b/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
>> index c7af5bc3b..d8e602527 100644
>> --- a/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -634,6 +634,8 @@ struct rtl8169_private {
>> struct rtl_fw *rtl_fw;
>>
>> u32 ocp_base;
>> +
>> + int retry_probeing;
>> };
>>
>> typedef void (*rtl_generic_fct)(struct rtl8169_private *tp);
>> @@ -5097,13 +5099,16 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>> if (!tp->phydev) {
>> return -ENODEV;
>> - } else if (!tp->phydev->drv) {
>> - /* Most chip versions fail with the genphy driver.
>> - * Therefore ensure that the dedicated PHY driver is loaded.
>> + } else if (tp->phydev->phy_id != RTL_GIGA_MAC_NONE) {
> You compare two completely different things here. The phy_id has nothing
> to do with the chip version enum.
>
>> + /* Most chip versions fail with the genphy driver, BUT do rerport valid IW
>> + * ID. Re-starting the module seem to fix the issue of non-functional driver.
>> */
>> - dev_err(&pdev->dev, "no dedicated PHY driver found for PHY ID 0x%08x, maybe realtek.ko needs to be added to initramfs?\n",
>> + dev_err(&pdev->dev,
>> + "no dedicated driver, but HW found: PHY PHY ID 0x%08x\n",
>> tp->phydev->phy_id);
>> - return -EUNATCH;
>> +
>> + dev_err(&pdev->dev, "trying re-probe few times..\n");
>> +
>> }
>>
>> tp->phydev->mac_managed_pm = 1;
>> @@ -5250,6 +5255,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> enum mac_version chipset;
>> struct net_device *dev;
>> u16 xid;
>> + int savederr = 0;
>>
>> dev = devm_alloc_etherdev(&pdev->dev, sizeof (*tp));
>> if (!dev)
>> @@ -5261,6 +5267,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> tp->dev = dev;
>> tp->pci_dev = pdev;
>> tp->supports_gmii = ent->driver_data == RTL_CFG_NO_GBIT ? 0 : 1;
>> + tp->retry_probeing = 0;
>> tp->eee_adv = -1;
>> tp->ocp_base = OCP_STD_PHY_BASE;
>>
>> @@ -5410,7 +5417,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>
>> pci_set_drvdata(pdev, tp);
>>
>> - rc = r8169_mdio_register(tp);
>> + savederr = r8169_mdio_register(tp);
>> +
>> + if (
>> + (tp->retry_probeing > 0) &&
>> + (savederr == -EAGAIN)
>> + ) {
>> + netdev_info(dev, " retry of probe requested..............");
>> + }
>> +
>> if (rc)
>> return rc;
>>
>> @@ -5435,6 +5450,14 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> if (pci_dev_run_wake(pdev))
>> pm_runtime_put_sync(&pdev->dev);
>>
>> + if (
>> + (tp->retry_probeing > 0) &&
>> + (savederr == -EAGAIN)
>> + ) {
>> + netdev_info(dev, " retry of probe requested..............");
>> + return savederr;
> You can not simply return here. You have to clean up.
>
>> + }
>> +
>> return 0;
>> }
>>
>> diff --git a/linux-5.14-rc4/drivers/net/phy/phy_device.c b/linux-5.14-rc4/drivers/net/phy/phy_device.c
>> index 5d5f9a9ee..59c6ac031 100644
> No mixing of changes in phylib and drivers.
>
>> --- a/linux-5.14-rc4/drivers/net/phy/phy_device.c
>> +++ b/linux-5.14-rc4/drivers/net/phy/phy_device.c
>> @@ -2980,6 +2980,9 @@ struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode)
>> }
>> EXPORT_SYMBOL_GPL(fwnode_get_phy_node);
>>
>> +
>> +static int phy_remove(struct device *dev);
>> +
> No forward declarations.
>
>> /**
>> * phy_probe - probe and init a PHY device
>> * @dev: device to probe and init
>> @@ -2988,13 +2991,22 @@ EXPORT_SYMBOL_GPL(fwnode_get_phy_node);
>> * set the state to READY (the driver's init function should
>> * set it to STARTING if needed).
>> */
>> +#define REDO_PROBE_TIMES 5
>> static int phy_probe(struct device *dev)
>> {
>> struct phy_device *phydev = to_phy_device(dev);
>> struct device_driver *drv = phydev->mdio.dev.driver;
>> struct phy_driver *phydrv = to_phy_driver(drv);
>> + int again = 0;
>> + int savederr = 0;
>> +again_retry:
>> int err = 0;
>>
>> + if (again > 0) {
>> + pr_err("%s: Re-probe %d of driver.....\n",
>> + phydrv->name, again);
>> + }
>> +
>> phydev->drv = phydrv;
>>
>> /* Disable the interrupt if the PHY doesn't support it
>> @@ -3013,6 +3025,17 @@ static int phy_probe(struct device *dev)
>>
>> if (phydev->drv->probe) {
>> err = phydev->drv->probe(phydev);
>> +
>> + /* If again requested. */
>> + if (err == -EAGAIN) {
> This doesn't make sense. You check the PHY driver probe return code,
> mixing it up with the MAC driver return code.
>
>> + again++;
>> + savederr = err;
>> + err = 0;
>> +
>> + pr_info("%s: EAGAIN: %d ...\n",
>> + phydrv->name, again);
>> + }
>> +
>> if (err)
>> goto out;
>> }
>> @@ -3081,6 +3104,20 @@ static int phy_probe(struct device *dev)
>>
>> mutex_unlock(&phydev->lock);
>>
>> + if ((savederr == -EAGAIN) &&
>> + ((again > 0) && (again < REDO_PROBE_TIMES))
>> + ) {
>> + pr_err("%s: Retry removal driver..\n",
>> + phydrv->name);
>> +
>> + phy_remove(dev);
>> +
>> + pr_err("%s: Re-probe driver..\n",
>> + phydrv->name);
>> + savederr = 0;
>> + goto again_retry;
>> + }
>> +
>> return err;
>> }
>>
>> @@ -3108,6 +3145,7 @@ static int phy_remove(struct device *dev)
>> return 0;
>> }
>>
>> +
>> static void phy_shutdown(struct device *dev)
>> {
>> struct phy_device *phydev = to_phy_device(dev);
>>
>>
>>
>> On 11.3.2021 18.43, gmail wrote:
>>> Heiner Kallweit kirjoitti 11.3.2021 klo 18.23:
>>>> On 11.03.2021 17:00, gmail wrote:
>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>
>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>
>>>>> Hi, There seems to he Something odd problem, maybe timing
>>>>> related. Stripped version not workingas expected. I get back to
>>>>> you, when i have it working.
>>>>>
>>>>> There's no point in working on your patch. W/o proper justification it
>>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>>> you actually have.
>>>>> FIRST please provide the requested logs and explain the actual problem
>>>>> (incl. the commit that caused the regression).
>>>>>
>>>>>
>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com
>>>>> <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll
>>>>> strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote: On
>>>>> Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi,
>>>>> Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On
>>>>> Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From
>>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
>>>>> 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020
>>>>> 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>> The driver installation determination made properly by checking
>>>>> PHY vs DRIVER id's. ---
>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70
>>>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2
>>>>> files changed, 72 insertions(+), 9 deletions(-) I would say that
>>>>> most of the code is debug prints. I tought that they are helpful
>>>>> to keep, they are using the debug calls, so they are not visible
>>>>> if user does not like those. You are missing the point of who
>>>>> are your users. Users want to have working device and the code.
>>>>> They don't need or like to debug their kernel. Thanks
>>>>>
>>>>> Hi, now i got time to tackle with this again :) .. I know the proposed fix is quite hack, BUT it does give a clue what is wrong.
>>>>>
>>>>> Something in subsystem is not working at the first time, but it needs to be reloaded to work ok (second time). So what I will do
>>>>> is that I try out re-do the module load within the module, if there is known HW id available but driver is not available, that
>>>>> would be much nicer and user friendly way.
>>>>>
>>>>>
>>>>> When the module setup it self nicely on first load, then can be the hunt for late-init of subsystem be checked out. Is the HW
>>>>> not brought up correct way during first time, or does the HW need time to brough up, or what is the cause.
>>>>>
>>>>> The justification is the same as all HW driver bugs, the improvement is always better to take in. Or do this patch have some-
>>>>> thing what other patches do not?
>>>>>
>>>>> Is there legit reason why NOT to improve something, that is clearly issue for others also than just me ? I will take on the
>>>>> task to fiddle with the module to get it more-less hacky and fully working version. Without the need for user to do something
>>>>> for the module to work.
>>>>>
>>>>> --Lauri J.
>>>>>
>>>>>
>>>> I have no clue what you're trying to say. The last patch wasn't acceptable at all.
>>>> If you want to submit a patch:
>>>>
>>>> - Follow kernel code style
>>>> - Explain what the exact problem is, what the root cause is, and how your patch fixes it
>>>> - Explain why you're sure that it doesn't break processing on other chip versions
>>>> and systems.
>>>>
>>> Ok, i'll make nice patch that has in comment what is the problem and how does the patch help the case at hand.
>>>
>>> I don't know the rootcause, but something in subsystem that possibly is initializing bit slowly, cause the reloading
>>>
>>> of the module provides working network connection, when done via insmod cycle. I'm not sure is it just a timing
>>>
>>> issue or what. I'd like to check where is the driver pointer populated, and put some debugs to see if the issue is just
>>>
>>> timing, let's see.
>>>
>>>
>>> The problem is that (1st load) fails, but there is valid HW found (the ID is known), when the hacky patch of mine
>>>
>>> is applied, the second time of loading module works ok, and network is connected ok etc.
>>>
>>>
>>> I make the change so that when the current HEAD code is going to return failure, i do check that if the HW id is read ok
>>>
>>> from the HW, then pass -EAGAIN ja try to load 5 times, sleeping 250ms in between.
>>>
>>>
>>> --Lauri J.
>>>
>>>
>>>
>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2021-08-11 13:17 ` Late @ Gmail
@ 2021-08-11 19:47 ` Heiner Kallweit
2021-08-12 14:58 ` Late @ Gmail
0 siblings, 1 reply; 57+ messages in thread
From: Heiner Kallweit @ 2021-08-11 19:47 UTC (permalink / raw)
To: Late @ Gmail; +Cc: netdev, nic_swsd
On 11.08.2021 15:17, Late @ Gmail wrote:
> Hi All,
>
> Ok, I will not send patch with the hacky-stuff anymore. I do realize the hacky stuff is not acceptable, but it is a starting point
>
> .. you gotta start from somewhere, and get some comments about the patch.
>
>
> That means that I need some help, what i'm trying to grasp is what the patch does, so that the driver
>
> works with my HW (witch needs the patch (hacky yeah) to work out of the boot ok).
>
>
> The modprobe reload does something to driver/hw/??? that it is ok, when the module's probe return zero at all times.
>
> .. that is hacky partly reason: I'm not familiar with kernel's code base yet -> It may seem hacky for many, but i'm
>
> trying to get picture in my head what and why works like it works.
>
>
> The hacky-bit works for me -> in principle the way to fix in concept is ok, now just to make it non-hacky and align
>
> with current architechture and design of overall kernel codebase.
>
>
> hmm, i'm thinking of debugging the module's reloading steps with stacktraces to figure out more and
>
> possibly make quirk bit(s) for re-probe within initial module load & handle unloading properly in
>
> between.
>
>
> So basicly what i'm trying to reproduce in boot-time is:
>
>
> modprobe -r r8169
>
> modprobe r8169
>
That's the interesting: find out why after a reload of the module the chip suddenly
provides the correct PHY ID. It shouldn't be something in probe() because this one
we execute on first load already. Maybe something related to remove().
E.g. you could check whether a pci_disable_device() / pci_enable_device()
cycle before r8169_mdio_register() makes a difference.
>
> Sequence.
>
>
> --Lauri
>
> On 11.8.2021 9.09, Heiner Kallweit wrote:
>> On 10.08.2021 23:50, Late @ Gmail wrote:
>>> Hi,
>>>
>>> Now I solved the reloading issue, and r8169 driver works line charm.
>>>
>> This patch is a complete hack and and in parts simply wrong.
>> In addition it misses the basics of how to submit a patch.
>> Quality hasn't improved since your first attempt, so better stop
>> trying to submit this to mainline.
>>
>>> Patch:
>>>
>>> From: Lauri Jakku <lja@lja.fi>
>>> Date: Mon, 9 Aug 2021 21:44:53 +0300
>>> Subject: [PATCH] net:realtek:r8169 driver load fix
>>>
>>> net:realtek:r8169 driver load fix
>>>
>>> Problem:
>>>
>>> The problem is that (1st load) fails, but there is valid
>>> HW found (the ID is known) and this patch is applied, the second
>>> time of loading module works ok, and network is connected ok
>>> etc.
>>>
>>> Solution:
>>>
>>> The driver will trust the HW that reports valid ID and then make
>>> re-loading of the module as it would being reloaded manually.
>>>
>>> I do check that if the HW id is read ok from the HW, then pass
>>> -EAGAIN ja try to load 5 times, sleeping 250ms in between.
>>>
>>> Signed-off-by: Lauri Jakku <lja@lja.fi>
>>> diff --git a/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c b/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
>>> index c7af5bc3b..d8e602527 100644
>>> --- a/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
>>> +++ b/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
>>> @@ -634,6 +634,8 @@ struct rtl8169_private {
>>> struct rtl_fw *rtl_fw;
>>>
>>> u32 ocp_base;
>>> +
>>> + int retry_probeing;
>>> };
>>>
>>> typedef void (*rtl_generic_fct)(struct rtl8169_private *tp);
>>> @@ -5097,13 +5099,16 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>> if (!tp->phydev) {
>>> return -ENODEV;
>>> - } else if (!tp->phydev->drv) {
>>> - /* Most chip versions fail with the genphy driver.
>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>> + } else if (tp->phydev->phy_id != RTL_GIGA_MAC_NONE) {
>> You compare two completely different things here. The phy_id has nothing
>> to do with the chip version enum.
>>
>>> + /* Most chip versions fail with the genphy driver, BUT do rerport valid IW
>>> + * ID. Re-starting the module seem to fix the issue of non-functional driver.
>>> */
>>> - dev_err(&pdev->dev, "no dedicated PHY driver found for PHY ID 0x%08x, maybe realtek.ko needs to be added to initramfs?\n",
>>> + dev_err(&pdev->dev,
>>> + "no dedicated driver, but HW found: PHY PHY ID 0x%08x\n",
>>> tp->phydev->phy_id);
>>> - return -EUNATCH;
>>> +
>>> + dev_err(&pdev->dev, "trying re-probe few times..\n");
>>> +
>>> }
>>>
>>> tp->phydev->mac_managed_pm = 1;
>>> @@ -5250,6 +5255,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> enum mac_version chipset;
>>> struct net_device *dev;
>>> u16 xid;
>>> + int savederr = 0;
>>>
>>> dev = devm_alloc_etherdev(&pdev->dev, sizeof (*tp));
>>> if (!dev)
>>> @@ -5261,6 +5267,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> tp->dev = dev;
>>> tp->pci_dev = pdev;
>>> tp->supports_gmii = ent->driver_data == RTL_CFG_NO_GBIT ? 0 : 1;
>>> + tp->retry_probeing = 0;
>>> tp->eee_adv = -1;
>>> tp->ocp_base = OCP_STD_PHY_BASE;
>>>
>>> @@ -5410,7 +5417,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>
>>> pci_set_drvdata(pdev, tp);
>>>
>>> - rc = r8169_mdio_register(tp);
>>> + savederr = r8169_mdio_register(tp);
>>> +
>>> + if (
>>> + (tp->retry_probeing > 0) &&
>>> + (savederr == -EAGAIN)
>>> + ) {
>>> + netdev_info(dev, " retry of probe requested..............");
>>> + }
>>> +
>>> if (rc)
>>> return rc;
>>>
>>> @@ -5435,6 +5450,14 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> if (pci_dev_run_wake(pdev))
>>> pm_runtime_put_sync(&pdev->dev);
>>>
>>> + if (
>>> + (tp->retry_probeing > 0) &&
>>> + (savederr == -EAGAIN)
>>> + ) {
>>> + netdev_info(dev, " retry of probe requested..............");
>>> + return savederr;
>> You can not simply return here. You have to clean up.
>>
>>> + }
>>> +
>>> return 0;
>>> }
>>>
>>> diff --git a/linux-5.14-rc4/drivers/net/phy/phy_device.c b/linux-5.14-rc4/drivers/net/phy/phy_device.c
>>> index 5d5f9a9ee..59c6ac031 100644
>> No mixing of changes in phylib and drivers.
>>
>>> --- a/linux-5.14-rc4/drivers/net/phy/phy_device.c
>>> +++ b/linux-5.14-rc4/drivers/net/phy/phy_device.c
>>> @@ -2980,6 +2980,9 @@ struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode)
>>> }
>>> EXPORT_SYMBOL_GPL(fwnode_get_phy_node);
>>>
>>> +
>>> +static int phy_remove(struct device *dev);
>>> +
>> No forward declarations.
>>
>>> /**
>>> * phy_probe - probe and init a PHY device
>>> * @dev: device to probe and init
>>> @@ -2988,13 +2991,22 @@ EXPORT_SYMBOL_GPL(fwnode_get_phy_node);
>>> * set the state to READY (the driver's init function should
>>> * set it to STARTING if needed).
>>> */
>>> +#define REDO_PROBE_TIMES 5
>>> static int phy_probe(struct device *dev)
>>> {
>>> struct phy_device *phydev = to_phy_device(dev);
>>> struct device_driver *drv = phydev->mdio.dev.driver;
>>> struct phy_driver *phydrv = to_phy_driver(drv);
>>> + int again = 0;
>>> + int savederr = 0;
>>> +again_retry:
>>> int err = 0;
>>>
>>> + if (again > 0) {
>>> + pr_err("%s: Re-probe %d of driver.....\n",
>>> + phydrv->name, again);
>>> + }
>>> +
>>> phydev->drv = phydrv;
>>>
>>> /* Disable the interrupt if the PHY doesn't support it
>>> @@ -3013,6 +3025,17 @@ static int phy_probe(struct device *dev)
>>>
>>> if (phydev->drv->probe) {
>>> err = phydev->drv->probe(phydev);
>>> +
>>> + /* If again requested. */
>>> + if (err == -EAGAIN) {
>> This doesn't make sense. You check the PHY driver probe return code,
>> mixing it up with the MAC driver return code.
>>
>>> + again++;
>>> + savederr = err;
>>> + err = 0;
>>> +
>>> + pr_info("%s: EAGAIN: %d ...\n",
>>> + phydrv->name, again);
>>> + }
>>> +
>>> if (err)
>>> goto out;
>>> }
>>> @@ -3081,6 +3104,20 @@ static int phy_probe(struct device *dev)
>>>
>>> mutex_unlock(&phydev->lock);
>>>
>>> + if ((savederr == -EAGAIN) &&
>>> + ((again > 0) && (again < REDO_PROBE_TIMES))
>>> + ) {
>>> + pr_err("%s: Retry removal driver..\n",
>>> + phydrv->name);
>>> +
>>> + phy_remove(dev);
>>> +
>>> + pr_err("%s: Re-probe driver..\n",
>>> + phydrv->name);
>>> + savederr = 0;
>>> + goto again_retry;
>>> + }
>>> +
>>> return err;
>>> }
>>>
>>> @@ -3108,6 +3145,7 @@ static int phy_remove(struct device *dev)
>>> return 0;
>>> }
>>>
>>> +
>>> static void phy_shutdown(struct device *dev)
>>> {
>>> struct phy_device *phydev = to_phy_device(dev);
>>>
>>>
>>>
>>> On 11.3.2021 18.43, gmail wrote:
>>>> Heiner Kallweit kirjoitti 11.3.2021 klo 18.23:
>>>>> On 11.03.2021 17:00, gmail wrote:
>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>
>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>
>>>>>> Hi, There seems to he Something odd problem, maybe timing
>>>>>> related. Stripped version not workingas expected. I get back to
>>>>>> you, when i have it working.
>>>>>>
>>>>>> There's no point in working on your patch. W/o proper justification it
>>>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>>>> you actually have.
>>>>>> FIRST please provide the requested logs and explain the actual problem
>>>>>> (incl. the commit that caused the regression).
>>>>>>
>>>>>>
>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com
>>>>>> <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll
>>>>>> strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote: On
>>>>>> Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi,
>>>>>> Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On
>>>>>> Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From
>>>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
>>>>>> 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020
>>>>>> 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>> The driver installation determination made properly by checking
>>>>>> PHY vs DRIVER id's. ---
>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70
>>>>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2
>>>>>> files changed, 72 insertions(+), 9 deletions(-) I would say that
>>>>>> most of the code is debug prints. I tought that they are helpful
>>>>>> to keep, they are using the debug calls, so they are not visible
>>>>>> if user does not like those. You are missing the point of who
>>>>>> are your users. Users want to have working device and the code.
>>>>>> They don't need or like to debug their kernel. Thanks
>>>>>>
>>>>>> Hi, now i got time to tackle with this again :) .. I know the proposed fix is quite hack, BUT it does give a clue what is wrong.
>>>>>>
>>>>>> Something in subsystem is not working at the first time, but it needs to be reloaded to work ok (second time). So what I will do
>>>>>> is that I try out re-do the module load within the module, if there is known HW id available but driver is not available, that
>>>>>> would be much nicer and user friendly way.
>>>>>>
>>>>>>
>>>>>> When the module setup it self nicely on first load, then can be the hunt for late-init of subsystem be checked out. Is the HW
>>>>>> not brought up correct way during first time, or does the HW need time to brough up, or what is the cause.
>>>>>>
>>>>>> The justification is the same as all HW driver bugs, the improvement is always better to take in. Or do this patch have some-
>>>>>> thing what other patches do not?
>>>>>>
>>>>>> Is there legit reason why NOT to improve something, that is clearly issue for others also than just me ? I will take on the
>>>>>> task to fiddle with the module to get it more-less hacky and fully working version. Without the need for user to do something
>>>>>> for the module to work.
>>>>>>
>>>>>> --Lauri J.
>>>>>>
>>>>>>
>>>>> I have no clue what you're trying to say. The last patch wasn't acceptable at all.
>>>>> If you want to submit a patch:
>>>>>
>>>>> - Follow kernel code style
>>>>> - Explain what the exact problem is, what the root cause is, and how your patch fixes it
>>>>> - Explain why you're sure that it doesn't break processing on other chip versions
>>>>> and systems.
>>>>>
>>>> Ok, i'll make nice patch that has in comment what is the problem and how does the patch help the case at hand.
>>>>
>>>> I don't know the rootcause, but something in subsystem that possibly is initializing bit slowly, cause the reloading
>>>>
>>>> of the module provides working network connection, when done via insmod cycle. I'm not sure is it just a timing
>>>>
>>>> issue or what. I'd like to check where is the driver pointer populated, and put some debugs to see if the issue is just
>>>>
>>>> timing, let's see.
>>>>
>>>>
>>>> The problem is that (1st load) fails, but there is valid HW found (the ID is known), when the hacky patch of mine
>>>>
>>>> is applied, the second time of loading module works ok, and network is connected ok etc.
>>>>
>>>>
>>>> I make the change so that when the current HEAD code is going to return failure, i do check that if the HW id is read ok
>>>>
>>>> from the HW, then pass -EAGAIN ja try to load 5 times, sleeping 250ms in between.
>>>>
>>>>
>>>> --Lauri J.
>>>>
>>>>
>>>>
>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: NET: r8168/r8169 identifying fix
2021-08-11 19:47 ` Heiner Kallweit
@ 2021-08-12 14:58 ` Late @ Gmail
0 siblings, 0 replies; 57+ messages in thread
From: Late @ Gmail @ 2021-08-12 14:58 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev, nic_swsd
Hi,
On 11.8.2021 22.47, Heiner Kallweit wrote:
> On 11.08.2021 15:17, Late @ Gmail wrote:
>> Hi All,
>>
>> Ok, I will not send patch with the hacky-stuff anymore. I do realize the hacky stuff is not acceptable, but it is a starting point
>>
>> .. you gotta start from somewhere, and get some comments about the patch.
>>
>>
>> That means that I need some help, what i'm trying to grasp is what the patch does, so that the driver
>>
>> works with my HW (witch needs the patch (hacky yeah) to work out of the boot ok).
>>
>>
>> The modprobe reload does something to driver/hw/??? that it is ok, when the module's probe return zero at all times.
>>
>> .. that is hacky partly reason: I'm not familiar with kernel's code base yet -> It may seem hacky for many, but i'm
>>
>> trying to get picture in my head what and why works like it works.
>>
>>
>> The hacky-bit works for me -> in principle the way to fix in concept is ok, now just to make it non-hacky and align
>>
>> with current architechture and design of overall kernel codebase.
>>
>>
>> hmm, i'm thinking of debugging the module's reloading steps with stacktraces to figure out more and
>>
>> possibly make quirk bit(s) for re-probe within initial module load & handle unloading properly in
>>
>> between.
>>
>>
>> So basicly what i'm trying to reproduce in boot-time is:
>>
>>
>> modprobe -r r8169
>>
>> modprobe r8169
>>
> That's the interesting: find out why after a reload of the module the chip suddenly
> provides the correct PHY ID. It shouldn't be something in probe() because this one
> we execute on first load already. Maybe something related to remove().
> E.g. you could check whether a pci_disable_device() / pci_enable_device()
> cycle before r8169_mdio_register() makes a difference.
First of all: Thank you for constructive feedback and hints!
I'll check if the ena/disa/ena cycle would do the trick :)
That has to wait till september.
>> Sequence.
>>
>>
>> --Lauri
>>
>> On 11.8.2021 9.09, Heiner Kallweit wrote:
>>> On 10.08.2021 23:50, Late @ Gmail wrote:
>>>> Hi,
>>>>
>>>> Now I solved the reloading issue, and r8169 driver works line charm.
>>>>
>>> This patch is a complete hack and and in parts simply wrong.
>>> In addition it misses the basics of how to submit a patch.
>>> Quality hasn't improved since your first attempt, so better stop
>>> trying to submit this to mainline.
>>>
>>>> Patch:
>>>>
>>>> From: Lauri Jakku <lja@lja.fi>
>>>> Date: Mon, 9 Aug 2021 21:44:53 +0300
>>>> Subject: [PATCH] net:realtek:r8169 driver load fix
>>>>
>>>> net:realtek:r8169 driver load fix
>>>>
>>>> Problem:
>>>>
>>>> The problem is that (1st load) fails, but there is valid
>>>> HW found (the ID is known) and this patch is applied, the second
>>>> time of loading module works ok, and network is connected ok
>>>> etc.
>>>>
>>>> Solution:
>>>>
>>>> The driver will trust the HW that reports valid ID and then make
>>>> re-loading of the module as it would being reloaded manually.
>>>>
>>>> I do check that if the HW id is read ok from the HW, then pass
>>>> -EAGAIN ja try to load 5 times, sleeping 250ms in between.
>>>>
>>>> Signed-off-by: Lauri Jakku <lja@lja.fi>
>>>> diff --git a/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c b/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
>>>> index c7af5bc3b..d8e602527 100644
>>>> --- a/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
>>>> +++ b/linux-5.14-rc4/drivers/net/ethernet/realtek/r8169_main.c
>>>> @@ -634,6 +634,8 @@ struct rtl8169_private {
>>>> struct rtl_fw *rtl_fw;
>>>>
>>>> u32 ocp_base;
>>>> +
>>>> + int retry_probeing;
>>>> };
>>>>
>>>> typedef void (*rtl_generic_fct)(struct rtl8169_private *tp);
>>>> @@ -5097,13 +5099,16 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>>>> tp->phydev = mdiobus_get_phy(new_bus, 0);
>>>> if (!tp->phydev) {
>>>> return -ENODEV;
>>>> - } else if (!tp->phydev->drv) {
>>>> - /* Most chip versions fail with the genphy driver.
>>>> - * Therefore ensure that the dedicated PHY driver is loaded.
>>>> + } else if (tp->phydev->phy_id != RTL_GIGA_MAC_NONE) {
>>> You compare two completely different things here. The phy_id has nothing
>>> to do with the chip version enum.
>>>
>>>> + /* Most chip versions fail with the genphy driver, BUT do rerport valid IW
>>>> + * ID. Re-starting the module seem to fix the issue of non-functional driver.
>>>> */
>>>> - dev_err(&pdev->dev, "no dedicated PHY driver found for PHY ID 0x%08x, maybe realtek.ko needs to be added to initramfs?\n",
>>>> + dev_err(&pdev->dev,
>>>> + "no dedicated driver, but HW found: PHY PHY ID 0x%08x\n",
>>>> tp->phydev->phy_id);
>>>> - return -EUNATCH;
>>>> +
>>>> + dev_err(&pdev->dev, "trying re-probe few times..\n");
>>>> +
>>>> }
>>>>
>>>> tp->phydev->mac_managed_pm = 1;
>>>> @@ -5250,6 +5255,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> enum mac_version chipset;
>>>> struct net_device *dev;
>>>> u16 xid;
>>>> + int savederr = 0;
>>>>
>>>> dev = devm_alloc_etherdev(&pdev->dev, sizeof (*tp));
>>>> if (!dev)
>>>> @@ -5261,6 +5267,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> tp->dev = dev;
>>>> tp->pci_dev = pdev;
>>>> tp->supports_gmii = ent->driver_data == RTL_CFG_NO_GBIT ? 0 : 1;
>>>> + tp->retry_probeing = 0;
>>>> tp->eee_adv = -1;
>>>> tp->ocp_base = OCP_STD_PHY_BASE;
>>>>
>>>> @@ -5410,7 +5417,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>
>>>> pci_set_drvdata(pdev, tp);
>>>>
>>>> - rc = r8169_mdio_register(tp);
>>>> + savederr = r8169_mdio_register(tp);
>>>> +
>>>> + if (
>>>> + (tp->retry_probeing > 0) &&
>>>> + (savederr == -EAGAIN)
>>>> + ) {
>>>> + netdev_info(dev, " retry of probe requested..............");
>>>> + }
>>>> +
>>>> if (rc)
>>>> return rc;
>>>>
>>>> @@ -5435,6 +5450,14 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>> if (pci_dev_run_wake(pdev))
>>>> pm_runtime_put_sync(&pdev->dev);
>>>>
>>>> + if (
>>>> + (tp->retry_probeing > 0) &&
>>>> + (savederr == -EAGAIN)
>>>> + ) {
>>>> + netdev_info(dev, " retry of probe requested..............");
>>>> + return savederr;
>>> You can not simply return here. You have to clean up.
>>>
>>>> + }
>>>> +
>>>> return 0;
>>>> }
>>>>
>>>> diff --git a/linux-5.14-rc4/drivers/net/phy/phy_device.c b/linux-5.14-rc4/drivers/net/phy/phy_device.c
>>>> index 5d5f9a9ee..59c6ac031 100644
>>> No mixing of changes in phylib and drivers.
>>>
>>>> --- a/linux-5.14-rc4/drivers/net/phy/phy_device.c
>>>> +++ b/linux-5.14-rc4/drivers/net/phy/phy_device.c
>>>> @@ -2980,6 +2980,9 @@ struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode)
>>>> }
>>>> EXPORT_SYMBOL_GPL(fwnode_get_phy_node);
>>>>
>>>> +
>>>> +static int phy_remove(struct device *dev);
>>>> +
>>> No forward declarations.
>>>
>>>> /**
>>>> * phy_probe - probe and init a PHY device
>>>> * @dev: device to probe and init
>>>> @@ -2988,13 +2991,22 @@ EXPORT_SYMBOL_GPL(fwnode_get_phy_node);
>>>> * set the state to READY (the driver's init function should
>>>> * set it to STARTING if needed).
>>>> */
>>>> +#define REDO_PROBE_TIMES 5
>>>> static int phy_probe(struct device *dev)
>>>> {
>>>> struct phy_device *phydev = to_phy_device(dev);
>>>> struct device_driver *drv = phydev->mdio.dev.driver;
>>>> struct phy_driver *phydrv = to_phy_driver(drv);
>>>> + int again = 0;
>>>> + int savederr = 0;
>>>> +again_retry:
>>>> int err = 0;
>>>>
>>>> + if (again > 0) {
>>>> + pr_err("%s: Re-probe %d of driver.....\n",
>>>> + phydrv->name, again);
>>>> + }
>>>> +
>>>> phydev->drv = phydrv;
>>>>
>>>> /* Disable the interrupt if the PHY doesn't support it
>>>> @@ -3013,6 +3025,17 @@ static int phy_probe(struct device *dev)
>>>>
>>>> if (phydev->drv->probe) {
>>>> err = phydev->drv->probe(phydev);
>>>> +
>>>> + /* If again requested. */
>>>> + if (err == -EAGAIN) {
>>> This doesn't make sense. You check the PHY driver probe return code,
>>> mixing it up with the MAC driver return code.
>>>
>>>> + again++;
>>>> + savederr = err;
>>>> + err = 0;
>>>> +
>>>> + pr_info("%s: EAGAIN: %d ...\n",
>>>> + phydrv->name, again);
>>>> + }
>>>> +
>>>> if (err)
>>>> goto out;
>>>> }
>>>> @@ -3081,6 +3104,20 @@ static int phy_probe(struct device *dev)
>>>>
>>>> mutex_unlock(&phydev->lock);
>>>>
>>>> + if ((savederr == -EAGAIN) &&
>>>> + ((again > 0) && (again < REDO_PROBE_TIMES))
>>>> + ) {
>>>> + pr_err("%s: Retry removal driver..\n",
>>>> + phydrv->name);
>>>> +
>>>> + phy_remove(dev);
>>>> +
>>>> + pr_err("%s: Re-probe driver..\n",
>>>> + phydrv->name);
>>>> + savederr = 0;
>>>> + goto again_retry;
>>>> + }
>>>> +
>>>> return err;
>>>> }
>>>>
>>>> @@ -3108,6 +3145,7 @@ static int phy_remove(struct device *dev)
>>>> return 0;
>>>> }
>>>>
>>>> +
>>>> static void phy_shutdown(struct device *dev)
>>>> {
>>>> struct phy_device *phydev = to_phy_device(dev);
>>>>
>>>>
>>>>
>>>> On 11.3.2021 18.43, gmail wrote:
>>>>> Heiner Kallweit kirjoitti 11.3.2021 klo 18.23:
>>>>>> On 11.03.2021 17:00, gmail wrote:
>>>>>>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> kirjoitti:
>>>>>>>
>>>>>>> On 15.04.2020 16:39, Lauri Jakku wrote:
>>>>>>>
>>>>>>> Hi, There seems to he Something odd problem, maybe timing
>>>>>>> related. Stripped version not workingas expected. I get back to
>>>>>>> you, when i have it working.
>>>>>>>
>>>>>>> There's no point in working on your patch. W/o proper justification it
>>>>>>> isn't acceptable anyway. And so far we still don't know which problem
>>>>>>> you actually have.
>>>>>>> FIRST please provide the requested logs and explain the actual problem
>>>>>>> (incl. the commit that caused the regression).
>>>>>>>
>>>>>>>
>>>>>>> 13. huhtik. 2020, 14.46, Lauri Jakku <ljakku77@gmail.com
>>>>>>> <mailto:ljakku77@gmail.com>> kirjoitti: Hi, Fair enough, i'll
>>>>>>> strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote: On
>>>>>>> Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi,
>>>>>>> Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On
>>>>>>> Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From
>>>>>>> 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
>>>>>>> 2001 From: Lauri Jakku <lja@iki.fi> Date: Mon, 13 Apr 2020
>>>>>>> 13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix
>>>>>>> The driver installation determination made properly by checking
>>>>>>> PHY vs DRIVER id's. ---
>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 70
>>>>>>> ++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2
>>>>>>> files changed, 72 insertions(+), 9 deletions(-) I would say that
>>>>>>> most of the code is debug prints. I tought that they are helpful
>>>>>>> to keep, they are using the debug calls, so they are not visible
>>>>>>> if user does not like those. You are missing the point of who
>>>>>>> are your users. Users want to have working device and the code.
>>>>>>> They don't need or like to debug their kernel. Thanks
>>>>>>>
>>>>>>> Hi, now i got time to tackle with this again :) .. I know the proposed fix is quite hack, BUT it does give a clue what is wrong.
>>>>>>>
>>>>>>> Something in subsystem is not working at the first time, but it needs to be reloaded to work ok (second time). So what I will do
>>>>>>> is that I try out re-do the module load within the module, if there is known HW id available but driver is not available, that
>>>>>>> would be much nicer and user friendly way.
>>>>>>>
>>>>>>>
>>>>>>> When the module setup it self nicely on first load, then can be the hunt for late-init of subsystem be checked out. Is the HW
>>>>>>> not brought up correct way during first time, or does the HW need time to brough up, or what is the cause.
>>>>>>>
>>>>>>> The justification is the same as all HW driver bugs, the improvement is always better to take in. Or do this patch have some-
>>>>>>> thing what other patches do not?
>>>>>>>
>>>>>>> Is there legit reason why NOT to improve something, that is clearly issue for others also than just me ? I will take on the
>>>>>>> task to fiddle with the module to get it more-less hacky and fully working version. Without the need for user to do something
>>>>>>> for the module to work.
>>>>>>>
>>>>>>> --Lauri J.
>>>>>>>
>>>>>>>
>>>>>> I have no clue what you're trying to say. The last patch wasn't acceptable at all.
>>>>>> If you want to submit a patch:
>>>>>>
>>>>>> - Follow kernel code style
>>>>>> - Explain what the exact problem is, what the root cause is, and how your patch fixes it
>>>>>> - Explain why you're sure that it doesn't break processing on other chip versions
>>>>>> and systems.
>>>>>>
>>>>> Ok, i'll make nice patch that has in comment what is the problem and how does the patch help the case at hand.
>>>>>
>>>>> I don't know the rootcause, but something in subsystem that possibly is initializing bit slowly, cause the reloading
>>>>>
>>>>> of the module provides working network connection, when done via insmod cycle. I'm not sure is it just a timing
>>>>>
>>>>> issue or what. I'd like to check where is the driver pointer populated, and put some debugs to see if the issue is just
>>>>>
>>>>> timing, let's see.
>>>>>
>>>>>
>>>>> The problem is that (1st load) fails, but there is valid HW found (the ID is known), when the hacky patch of mine
>>>>>
>>>>> is applied, the second time of loading module works ok, and network is connected ok etc.
>>>>>
>>>>>
>>>>> I make the change so that when the current HEAD code is going to return failure, i do check that if the HW id is read ok
>>>>>
>>>>> from the HW, then pass -EAGAIN ja try to load 5 times, sleeping 250ms in between.
>>>>>
>>>>>
>>>>> --Lauri J.
>>>>>
>>>>>
>>>>>
>>>>>
^ permalink raw reply [flat|nested] 57+ messages in thread
* NET: r8168/r8169 identifying fix
@ 2020-04-13 10:31 Lauri Jakku
0 siblings, 0 replies; 57+ messages in thread
From: Lauri Jakku @ 2020-04-13 10:31 UTC (permalink / raw)
To: netdev, Heiner Kallweit, nic_swsd
[-- Attachment #1: Type: text/plain, Size: 6129 bytes --]
From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Mon, 13 Apr 2020 13:18:35 +0300
Subject: [PATCH] NET: r8168/r8169 identifying fix
The driver installation determination made properly by
checking PHY vs DRIVER id's.
---
drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
drivers/net/phy/mdio_bus.c | 11 +++-
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..1ea6f121b561 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
{
struct pci_dev *pdev = tp->pci_dev;
struct mii_bus *new_bus;
+ u32 phydev_id = 0;
+ u32 phydrv_id = 0;
+ u32 phydrv_id_mask = 0;
int ret;
new_bus = devm_mdiobus_alloc(&pdev->dev);
@@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
new_bus->write = r8169_mdio_write_reg;
ret = mdiobus_register(new_bus);
+ dev_info(&pdev->dev,
+ "mdiobus_register: %s, %d\n",
+ new_bus->id, ret);
if (ret)
return ret;
tp->phydev = mdiobus_get_phy(new_bus, 0);
+
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ /* tp -> phydev ok */
+ int everything_OK = 0;
+
+ /* Check driver id versus phy */
+
+ if (tp->phydev->drv) {
+ u32 phydev_masked = 0xBEEFDEAD;
+ u32 drv_masked = ~0;
+ u32 phydev_match = ~0;
+ u32 drv_match = 0xDEADBEEF;
+
+ phydev_id = tp->phydev->phy_id;
+ phydrv_id = tp->phydev->drv->phy_id;
+ phydrv_id_mask = tp->phydev->drv->phy_id_mask;
+
+ drv_masked = phydrv_id & phydrv_id_mask;
+ phydev_masked = phydev_id & phydrv_id_mask;
+
+ dev_debug(&pdev->dev,
+ "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
+ new_bus->id, phydev_id, phydev_masked,
+ phydrv_id, drv_masked);
+
+ phydev_match = phydev_masked & drv_masked;
+ phydev_match = phydev_match == phydev_masked;
+
+ drv_match = phydev_masked & drv_masked;
+ drv_match = drv_match == drv_masked;
+
+ dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
+ new_bus->id, phydev_match, drv_match);
+
+ everything_OK = (phydev_match == drv_match);
+ }
+
+ if (!everything_OK) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver
+ * is loaded.
+ */
+ dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
@@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
+ dev_dbg(&pdev->dev, "init: MAC\n");
rtl_init_mac_address(tp);
dev->ethtool_ops = &rtl8169_ethtool_ops;
@@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->hw_features |= NETIF_F_RXFCS;
jumbo_max = rtl_jumbo_max(tp);
+ dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
if (jumbo_max)
dev->max_mtu = jumbo_max;
+ dev_dbg(&pdev->dev, "init: irq mask\n");
rtl_set_irq_mask(tp);
tp->fw_name = rtl_chip_infos[chipset].fw_name;
+ dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
&tp->counters_phys_addr,
@@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!tp->counters)
return -ENOMEM;
+ dev_dbg(&pdev->dev, "init: set driver data\n");
pci_set_drvdata(pdev, dev);
+ dev_dbg(&pdev->dev, "init: register mdio\n");
rc = r8169_mdio_register(tp);
+ dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
if (rc)
return rc;
/* chip gets powered up in rtl_open() */
+ dev_dbg(&pdev->dev, "init: pll pwr down\n");
rtl_pll_power_down(tp);
rc = register_netdev(dev);
+ dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
if (rc)
goto err_mdio_unregister;
@@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (pci_dev_run_wake(pdev))
pm_runtime_put_sync(&pdev->dev);
+ dev_dbg(&pdev->dev, "init: ALL DONE!\n");
+
return 0;
err_mdio_unregister:
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 522760c8bca6..719ea48164f6 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
{
struct mdio_device *mdiodev = bus->mdio_map[addr];
+ struct phy_device *rv = NULL;
+
+ pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
if (!mdiodev)
return NULL;
@@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
return NULL;
- return container_of(mdiodev, struct phy_device, mdio);
+ rv = container_of(mdiodev, struct phy_device, mdio);
+ pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
+ bus->id, addr, mdiodev, rv);
+ return rv;
}
EXPORT_SYMBOL(mdiobus_get_phy);
@@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
bus->state = MDIOBUS_REGISTERED;
- pr_info("%s: probed\n", bus->name);
+ pr_info("%s: probed (mdiobus_register)\n", bus->name);
return 0;
error:
+ pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
while (--i >= 0) {
mdiodev = bus->mdio_map[i];
if (!mdiodev)
--
2.26.0
--
Br,
Lauri J.
[-- Attachment #2: NET-r8169-module-enchansments.patch --]
[-- Type: text/x-patch, Size: 6110 bytes --]
From 2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00 2001
From: Lauri Jakku <lja@iki.fi>
Date: Mon, 13 Apr 2020 13:18:35 +0300
Subject: [PATCH] NET: r8168/r8169 identifying fix
The driver installation determination made properly by
checking PHY vs DRIVER id's.
---
drivers/net/ethernet/realtek/r8169_main.c | 70 ++++++++++++++++++++---
drivers/net/phy/mdio_bus.c | 11 +++-
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index bf5bf05970a2..1ea6f121b561 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5149,6 +5149,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
{
struct pci_dev *pdev = tp->pci_dev;
struct mii_bus *new_bus;
+ u32 phydev_id = 0;
+ u32 phydrv_id = 0;
+ u32 phydrv_id_mask = 0;
int ret;
new_bus = devm_mdiobus_alloc(&pdev->dev);
@@ -5165,20 +5168,62 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
new_bus->write = r8169_mdio_write_reg;
ret = mdiobus_register(new_bus);
+ dev_info(&pdev->dev,
+ "mdiobus_register: %s, %d\n",
+ new_bus->id, ret);
if (ret)
return ret;
tp->phydev = mdiobus_get_phy(new_bus, 0);
+
if (!tp->phydev) {
mdiobus_unregister(new_bus);
return -ENODEV;
- } else if (!tp->phydev->drv) {
- /* Most chip versions fail with the genphy driver.
- * Therefore ensure that the dedicated PHY driver is loaded.
- */
- dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
- mdiobus_unregister(new_bus);
- return -EUNATCH;
+ } else {
+ /* tp -> phydev ok */
+ int everything_OK = 0;
+
+ /* Check driver id versus phy */
+
+ if (tp->phydev->drv) {
+ u32 phydev_masked = 0xBEEFDEAD;
+ u32 drv_masked = ~0;
+ u32 phydev_match = ~0;
+ u32 drv_match = 0xDEADBEEF;
+
+ phydev_id = tp->phydev->phy_id;
+ phydrv_id = tp->phydev->drv->phy_id;
+ phydrv_id_mask = tp->phydev->drv->phy_id_mask;
+
+ drv_masked = phydrv_id & phydrv_id_mask;
+ phydev_masked = phydev_id & phydrv_id_mask;
+
+ dev_debug(&pdev->dev,
+ "%s: ID Check: (%x -> %x), drv (%x -> %x)\n",
+ new_bus->id, phydev_id, phydev_masked,
+ phydrv_id, drv_masked);
+
+ phydev_match = phydev_masked & drv_masked;
+ phydev_match = phydev_match == phydev_masked;
+
+ drv_match = phydev_masked & drv_masked;
+ drv_match = drv_match == drv_masked;
+
+ dev_debug(&pdev->dev, "%s: ID Check: %x == %x\n",
+ new_bus->id, phydev_match, drv_match);
+
+ everything_OK = (phydev_match == drv_match);
+ }
+
+ if (!everything_OK) {
+ /* Most chip versions fail with the genphy driver.
+ * Therefore ensure that the dedicated PHY driver
+ * is loaded.
+ */
+ dev_err(&pdev->dev, "realtek.ko not loaded, maybe it needs to be added to initramfs?\n");
+ mdiobus_unregister(new_bus);
+ return -EUNATCH;
+ }
}
/* PHY will be woken up in rtl_open() */
@@ -5435,6 +5480,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
+ dev_dbg(&pdev->dev, "init: MAC\n");
rtl_init_mac_address(tp);
dev->ethtool_ops = &rtl8169_ethtool_ops;
@@ -5483,12 +5529,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->hw_features |= NETIF_F_RXFCS;
jumbo_max = rtl_jumbo_max(tp);
+ dev_dbg(&pdev->dev, "init: jumbo max: %d\n", jumbo_max);
if (jumbo_max)
dev->max_mtu = jumbo_max;
+ dev_dbg(&pdev->dev, "init: irq mask\n");
rtl_set_irq_mask(tp);
tp->fw_name = rtl_chip_infos[chipset].fw_name;
+ dev_dbg(&pdev->dev, "init: FW name: %s\n", tp->fw_name);
tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
&tp->counters_phys_addr,
@@ -5496,16 +5545,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!tp->counters)
return -ENOMEM;
+ dev_dbg(&pdev->dev, "init: set driver data\n");
pci_set_drvdata(pdev, dev);
+ dev_dbg(&pdev->dev, "init: register mdio\n");
rc = r8169_mdio_register(tp);
+ dev_dbg(&pdev->dev, "init: mdio register: %d\n", rc);
if (rc)
return rc;
/* chip gets powered up in rtl_open() */
+ dev_dbg(&pdev->dev, "init: pll pwr down\n");
rtl_pll_power_down(tp);
rc = register_netdev(dev);
+ dev_dbg(&pdev->dev, "init: netdev register: %d\n", rc);
if (rc)
goto err_mdio_unregister;
@@ -5525,6 +5579,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (pci_dev_run_wake(pdev))
pm_runtime_put_sync(&pdev->dev);
+ dev_dbg(&pdev->dev, "init: ALL DONE!\n");
+
return 0;
err_mdio_unregister:
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 522760c8bca6..719ea48164f6 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -112,6 +112,9 @@ EXPORT_SYMBOL(mdiobus_unregister_device);
struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
{
struct mdio_device *mdiodev = bus->mdio_map[addr];
+ struct phy_device *rv = NULL;
+
+ pr_debug("mii_bus %s addr %d, %p\n", bus->id, addr, mdiodev);
if (!mdiodev)
return NULL;
@@ -119,7 +122,10 @@ struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
if (!(mdiodev->flags & MDIO_DEVICE_FLAG_PHY))
return NULL;
- return container_of(mdiodev, struct phy_device, mdio);
+ rv = container_of(mdiodev, struct phy_device, mdio);
+ pr_debug("mii_bus OK? %s addr %d, %p -> %p\n",
+ bus->id, addr, mdiodev, rv);
+ return rv;
}
EXPORT_SYMBOL(mdiobus_get_phy);
@@ -645,10 +651,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
mdiobus_setup_mdiodev_from_board_info(bus, mdiobus_create_device);
bus->state = MDIOBUS_REGISTERED;
- pr_info("%s: probed\n", bus->name);
+ pr_info("%s: probed (mdiobus_register)\n", bus->name);
return 0;
error:
+ pr_err("%s: Error while in mdiobus_register: %d\n", bus->name, err);
while (--i >= 0) {
mdiodev = bus->mdio_map[i];
if (!mdiodev)
--
2.26.0
^ permalink raw reply related [flat|nested] 57+ messages in thread
end of thread, other threads:[~2021-08-12 14:58 UTC | newest]
Thread overview: 57+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-13 10:30 NET: r8168/r8169 identifying fix Lauri Jakku
2020-04-13 10:58 ` Leon Romanovsky
2020-04-13 11:02 ` Lauri Jakku
2020-04-13 11:34 ` Leon Romanovsky
2020-04-13 11:46 ` Lauri Jakku
[not found] ` <d3adc7f2-06bb-45bc-ab02-3d443999cefd@gmail.com>
2020-04-15 16:18 ` Heiner Kallweit
[not found] ` <4860e57e-93e4-24f5-6103-fa80acbdfa0d@pp.inet.fi>
2020-04-16 18:26 ` Heiner Kallweit
2020-04-16 18:37 ` Lauri Jakku
2020-04-16 19:58 ` Lauri Jakku
2020-04-16 20:02 ` Heiner Kallweit
2020-04-16 20:10 ` Lauri Jakku
2020-04-16 20:38 ` Lauri Jakku
2020-04-16 20:50 ` Heiner Kallweit
2020-04-17 6:23 ` Lauri Jakku
2020-04-17 7:30 ` Lauri Jakku
2020-04-17 8:57 ` Heiner Kallweit
2020-04-18 11:06 ` Lauri Jakku
2020-04-18 18:46 ` Lauri Jakku
2020-04-19 15:09 ` Lauri Jakku
2020-04-19 16:49 ` Lauri Jakku
2020-04-19 16:00 ` Heiner Kallweit
2020-04-19 21:00 ` Lauri Jakku
2020-04-20 19:56 ` Lauri Jakku
2020-05-01 19:12 ` Lauri Jakku
2020-05-02 17:56 ` Lauri Jakku
2020-05-02 22:48 ` Lauri Jakku
[not found] ` <5cdc7f73-b109-2a37-8473-12889506b6a9@pp.inet.fi>
2020-05-02 23:15 ` Heiner Kallweit
2020-05-03 0:11 ` Lauri Jakku
2020-05-03 1:34 ` Lauri Jakku
2020-05-03 2:28 ` Lauri Jakku
2020-05-03 8:33 ` Heiner Kallweit
2020-05-03 13:54 ` Lauri Jakku
2020-05-19 5:15 ` Lauri Jakku
2020-05-11 13:09 ` Lauri Jakku
2021-03-11 16:00 ` gmail
2021-03-11 16:23 ` Heiner Kallweit
2021-03-11 16:43 ` gmail
2021-08-10 21:50 ` Late @ Gmail
2021-08-11 6:09 ` Heiner Kallweit
2021-08-11 13:17 ` Late @ Gmail
2021-08-11 19:47 ` Heiner Kallweit
2021-08-12 14:58 ` Late @ Gmail
2020-04-13 12:01 ` Lauri Jakku
2020-04-13 12:18 ` Leon Romanovsky
2020-04-13 14:44 ` Lauri Jakku
2020-04-13 15:33 ` Heiner Kallweit
2020-04-13 15:50 ` Lauri Jakku
2020-04-13 15:54 ` Heiner Kallweit
2020-04-13 16:10 ` Lauri Jakku
2020-04-13 16:17 ` Heiner Kallweit
2020-04-13 16:37 ` Lauri Jakku
2020-04-13 11:06 ` Lauri Jakku
2020-04-13 11:28 ` Heiner Kallweit
2020-04-13 11:40 ` Lauri Jakku
2020-04-13 11:57 ` Heiner Kallweit
2020-04-13 12:04 ` Lauri Jakku
2020-04-13 10:31 Lauri Jakku
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.