kernel/drivers/net/ethernet/realtek/r8169_main.c, branch linux-5.8.y

r8169: fix issue with forced threading in combination with shared interrupts

2020-11-01T11:45:39Z

[ Upstream commit 2734a24e6e5d18522fbf599135c59b82ec9b2c9e ] As reported by Serge flag IRQF_NO_THREAD causes an error if the interrupt is actually shared and the other driver(s) don't have this flag set. This situation can occur if a PCI(e) legacy interrupt is used in combination with forced threading. There's no good way to deal with this properly, therefore we have to remove flag IRQF_NO_THREAD. For fixing the original forced threading issue switch to napi_schedule(). Fixes: 424a646e072a ("r8169: fix operation under forced interrupt threading") Link: https://www.spinics.net/lists/netdev/msg694960.html Reported-by: Serge Belyshev Signed-off-by: Heiner Kallweit Tested-by: Serge Belyshev Link: https://lore.kernel.org/r/b5b53bfe-35ac-3768-85bf-74d1290cf394@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

r8169: fix operation under forced interrupt threading

2020-10-29T09:07:07Z

[ Upstream commit 424a646e072a887aa87283b53aa6f8b19c2a7bef ] For several network drivers it was reported that using __napi_schedule_irqoff() is unsafe with forced threading. One way to fix this is switching back to __napi_schedule, but then we lose the benefit of the irqoff version in general. As stated by Eric it doesn't make sense to make the minimal hard irq handlers in drivers using NAPI a thread. Therefore ensure that the hard irq handler is never thread-ified. Fixes: 9a899a35b0d6 ("r8169: switch to napi_schedule_irqoff") Link: https://lkml.org/lkml/2020/10/18/19 Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/4d3ef84a-c812-5072-918a-22a6f6468310@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

r8169: fix data corruption issue on RTL8402

2020-10-29T09:07:03Z

[ Upstream commit ef9da46ddef071e1bbb943afbbe9b38771855554 ] Petr reported that after resume from suspend RTL8402 partially truncates incoming packets, and re-initializing register RxConfig before the actual chip re-initialization sequence is needed to avoid the issue. Reported-by: Petr Tesarik Proposed-by: Petr Tesarik Tested-by: Petr Tesarik Signed-off-by: Heiner Kallweit Signed-off-by: Greg Kroah-Hartman

r8169: fix RTL8168f/RTL8411 EPHY config

2020-10-14T09:55:54Z

[ Upstream commit 709a16be0593c08190982cfbdca6df95e6d5823b ] Mistakenly bit 2 was set instead of bit 3 as in the vendor driver. Fixes: a7a92cf81589 ("r8169: sync PCIe PHY init with vendor driver 8.047.01") Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

r8169: consider that PHY reset may still be in progress after applying firmware

2020-10-14T09:55:48Z

commit 47dda78671a3d5cee3fb2229e37997d2ac8a3b54 upstream. Some firmware files trigger a PHY soft reset and don't wait for it to be finished. PHY register writes directly after applying the firmware may fail or provide unexpected results therefore. Fix this by waiting for bit BMCR_RESET to be cleared after applying firmware. There's nothing wrong with the referenced change, it's just that the fix will apply cleanly only after this change. Fixes: 89fbd26cca7e ("r8169: fix firmware not resetting tp->ocp_base") Signed-off-by: Heiner Kallweit Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

r8169: fix firmware not resetting tp->ocp_base

2020-06-21T00:31:26Z

Typically the firmware takes care that tp->ocp_base is reset to its default value. That's not the case (at least) for RTL8117. As a result subsequent PHY access reads/writes the wrong page and the link is broken. Fix this be resetting tp->ocp_base explicitly. Fixes: 229c1e0dfd3d ("r8169: load firmware for RTL8168fp/RTL8117") Reported-by: Aaron Ma Tested-by: Aaron Ma Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller

r8169: fix failing WoL

2020-06-04T22:51:54Z

Th referenced change added an extra hw reset to rtl8169_net_suspend() what makes WoL fail on few chip versions. Therefore skip the extra reset if we're going down and WoL is enabled. In rtl_shutdown() rtl8169_hw_reset() is called by rtl8169_net_suspend() already if needed, therefore avoid issues issue by removing the extra call. The fix was tested on a system with RTL8168g. Meanwhile rtl8169_hw_reset() does more than a hw reset and should be renamed. But that's net-next material. Fixes: 8ac8e8c64b53 ("r8169: make rtl8169_down central chip quiesce function") Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller

r8169: improve handling power management ops

2020-05-31T04:36:55Z

Simplify handling the power management callbacks. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller

r8169: make rtl8169_down central chip quiesce function

2020-05-31T04:36:55Z

Functionality for quiescing the chip is spread across different functions currently. Move it to rtl8169_down(). Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller

r8169: move some calls to rtl8169_hw_reset

2020-05-31T04:36:55Z

Move calls that are needed before and after calling rtl8169_hw_reset() into this function. This requires to move the function in the code. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller